¿Qué usarías para implementar un servidor de archivos rápido y liviano?

Question

Necesito tener como parte de una aplicación de escritorio un servidor de archivos que debería responder lo más rápido posible a las solicitudes de transferencia de archivos (desde clientes remotos, generalmente ubicados en la misma LAN).Habrá muchas solicitudes de archivos de tamaño pequeño.El servidor debería poder proporcionar servicios de carga y descarga.

No estoy limitado a ninguna tecnología en particular, por lo que estoy abierto a cualquier lenguaje de programación, kit de herramientas y biblioteca, siempre que puedan ejecutarse en Windows.

Mi opinión inicial es optar por una implementación de C/C++ utilizando Windows Sockets o utilizar los servicios proporcionados por bibliotecas como Boost (asio o similares).También pensé en Erlang, pero tendré que aprenderlo, por lo que los beneficios de rendimiento deberían justificar el mayor tiempo de desarrollo debido a tener que aprender el idioma.

EDICIÓN ÚLTIMA:Aprecio las respuestas que dicen usar FTP o HTTP o básicamente cualquier cosa que ya haya sido creada, pero considerando que aún quieres escribir uno desde cero, ¿qué harías?

Answer 1

Para las subidas frecuentes de archivos pequeños, la forma más rápida sería la de implementar su propio protocolo propietario, pero eso requeriría una cantidad considerable de trabajo - y también sería no estándar, es decir, la integración futura sería difícil a menos que esté capaz de implementar el protocolo en cualquier cliente que va a apoyar. Si decide hacerlo de todos modos, esta es mi sugerencia para un protocolo simple:

1. Comando: 1 byte para identificar qué va a hacer:. (0x01 para la solicitud de carga, 0x02 para la solicitud de descarga, 0x11 para la respuesta de carga, 0x12 para la respuesta de descarga, etc)
nombre
2. del archivo: se puede fijar de tamaño o precedido de un byte para la longitud (suponiendo que el nombre es menos de 255 bytes)
3. Suma de control, por ejemplo MD5 (si solicitud de carga o descarga respuesta)
4. Tamaño del archivo (si es solicitud de carga o descarga respuesta)
5. carga útil (de solicitud de carga o descarga respuesta)

Esto podría ser implementado en la parte superior de un socket TCP simple. También puede utilizar UDP, evitando el costo de establecer una conexión, pero en este caso, usted tiene que tratar con el control de la retransmisión.

Antes de decidir implementar su propio protocolo, echar un vistazo a las bibliotecas HTTP como libcurl, se podría garantizar que utiliza el servidor de comandos estándar HTTP GET como para su descarga y POST para cargar. Esto ahorraría mucho trabajo y usted será capaz de probar la descarga con cualquier navegador web.

Otra sugerencia para mejorar el rendimiento es usar el archivo de depósito no es el sistema de archivos, sino algo así como SQLite. Puede crear una sola tabla que contiene una columna de carbón para el nombre de archivo y una columna de blob para el contenido del archivo. Desde SQLite es ligero y hace un almacenamiento en caché eficiente, tendrá mayor parte del tiempo evitar la sobrecarga de acceso al disco.

Estoy asumiendo que no es necesario autenticación de cliente.

Por último: si bien C ++ es su preferencia para darle velocidad código nativo cruda, rara vez este es el cuello de botella importante en este tipo de aplicación. Lo más probable será el acceso al disco y ancho de banda de red. Estoy mencionando esto porque en Java que probablemente va a ser capaz de hacer un servlet a hacer exactamente lo mismo (mediante HTTP GET y POST para su descarga para la carga) con menos de 100 líneas de código. Derby en lugar de utilizar SQLite en este caso, puesto que en cualquier contenedor servlet (Tomcat, Glassfish, etc) y se hace.

Answer 2

¿Por qué no simplemente ir con ftp?Debería poder encontrar una implementación de servidor adecuada en cualquier idioma, y ​​también bibliotecas de acceso de cliente.

Suena como una gran reinvención de ruedas.Por supuesto, FTP no es ideal y tiene algunos puntos extraños, pero...está ahí, es estándar, bien conocido y ya está ampliamente implementado.

Answer 3

Si todas las máquinas están funcionando en Windows en la misma LAN, ¿por qué necesita un servidor en absoluto? ¿Por qué no simplemente utilizar el uso compartido de archivos de Windows?

Answer 4

Yo sugeriría a no utilizar FTP o SFTP, o cualquier otra técnica orientado a la conexión. En su lugar, ir a por un protocolo sin conexión o técnica.

La razón es que, si se requiere una gran cantidad de archivos pequeños que se cargan o descargan, y la respuesta debe ser lo más rápido posible, se quiere evitar el costo de la creación y la destrucción de las conexiones.

Yo sugeriría que se mire, ya sea usando una aplicación existente o implementar su propio servidor HTTP o HTTPS / servicio.

Answer 5

Sus cuellos de botella es probable que venir de una de las siguientes fuentes:

• Disco duro de E / S - El WD VelociRaptor se supone que tiene una velocidad de acceso aleatorio de alrededor de 100 MB / s. Además, es importante saber si lo configura como RAID0,1,5 o lo que no tienen. Algunos leen rápido pero escribir lento. Las compensaciones.

• Red de E / S - Asumiendo que usted tiene los discos duros más rápidos en una configuración RAID rápido, a menos que utilice Gbit / S, la red será lenta. Si las tuberías son grandes, todavía necesita que le proporcionen los datos.

• La memoria caché - El en memoria caché se necesita del sistema de archivos que ser lo suficientemente grande como para amortiguar toda la red de E / S para que no se hace más lento. Esto requerirá grandes cantidades de memoria para el tipo de trabajo que usted está mirando.

• Estructura del sistema de archivos - Asumiendo que usted tiene gigabytes de memoria, entonces el cuello de botella más probable será la estructura de datos que se utiliza para el sistema de archivos. Si la estructura del sistema de archivos es engorroso que le hará perder tiempo.

Si se asume que todos los demás problemas se resuelven, entonces qué se preocupan por su propia aplicación. Nótese, que la mayoría de los cuellos de botella están fuera de su control de software. Por lo tanto, si se codifican en C / C ++ o utilizar bibliotecas específicas, todavía estar a merced del sistema operativo y hardware.

Answer 6

Parece que usted debe utilizar un (SSH) del servidor , es cortafuegos / NAT seguro, seguro, y ya hace lo que quiere y más. También es posible usar archivos SAMBA o ventanas para compartir una implementación más sencilla.

Answer 7

¿Por qué no utilizar algo que existe, por ejemplo, un servidor Web normal, maneja una gran cantidad de archivos pequeños (imágenes) muy bien y rápido.

Y un montón de personas ya pasaron tiempo en la optimización del código.

Y la segunda ventaja es que la transferencia se realiza con HTTP, que es un protocolo establecido. Y se cambia fácilmente a SSL si necesita más seguridad.

En las subidas, que tampoco son un problema con un módulo de script o costumbre - con el mismo método también se puede añadir la autorización

.

Mientras que no es necesario buscar dinámicamente los archivos que supongo que esto sería una de las mejores soluciones.

Answer 8

Es una nueva parte de una aplicación de escritorio existente? ¿Cuál es la meta del servidor? ¿Se protege los archivos que se cargan / descargan y proporciona autenticación y / o autorización? ¿Proporciona algún tipo de estructura para los archivos que se almacenan en?

Una opción puede ser la instalación de Apache HTTP Server en la máquina y servir al archivo a través de eso. Utilizar POST para cargar y descargar GET.

Si los clientes están dentro de una LAN se puede no solo compartir una unidad?