SoloCodigo

En la API de sockets hay una funcion que sirve para enviar archivos directamente , pero la verdad la unica vez qaue la prve no me funciono porque no supe como usarla...

Sin embargo lo otro, es decir lo de linea a linea, no es tanto de linea a linea, sino el tamaño de bufer que quieras enviar.

Si lo haces bien , no tiene porque perder calidad, he hecho varios programas de transmision de archivos, incluso de video y nunca a perdido calidad.

Lo que creo que le paso a tu amigo es que si el dice que lo envio linea a linea, esque manipulo un archivo binario, con funciones para manejar archivos de texto, por eso perdio calidad logicamente, pero en condiciones normales , si haces bien el prgrama, no tendras que perder calidad de nada, eso hay que tener en cuenta los siguientes aspectos:

1-abrir el archivo de manera correcta
Si solo vas a enviar archivos de texto lo mejor es que manipules funciones para archivops de texto, sinoi, es decir si vas a utilizar tanto binarios como de texto, lo mejor es que todo lo uses en modo binario.
2-definir el tamaño del buffer
Segun las caracteristicas de tu red, el tamaño del archivo, e incluso el ti`po de particion, deberas escojer un tamaño de buffer adecuado, aunque este aspecto solo afecta a nivel de rendimiento, más no de efectividad.
3-Basura en los buffrer
al trabajar enviando informacion de un lado a otro, es muy importante serciorarce que el bufefr este limpio siempre, solia trabajar con la funcion memset, pero despues de algunas pruebas con algunos compialdores en linux, me di cuenta que esta funcion deja rartros de basura, asi que es más aconsejable que elabores tu mismo una funcion que llene todo el buffer con caracteres null, antes de efectuar cualquier operacion.
4-armado
Este es tal vez el aspecto más critico, porque la mayoria de los errores... como el de tu amigo, que el sonido perdio calidad... se deben al mal ensamblado del archivo en la parte de recepcion...
Aunque es bastante dispendioso, es necesario que hagas pruebas pàso por paso y analices el contenido del buffer que se lee del disco, y luego se envia, y en el programa que recepciona, verificar lo que se recibe y lo que se copia.. uno por uno....
Como esto es tan canson, he desarrolado mi propia estartegia y esperoq ue te sirva:

1-Crear un archivo de texto que tenga como minimo el tamaño de tres veces el buffer que se lee, esto con el fin de hacer seguimiento a la primera, ultima e intermedia lectura y correspondiente envio de buffer.
2-La idea es verificar que una vez todos los envios se hagan correctamente, el archivo resultante en el destino, tenga el mismo pero que el archivo de origen, y por supuesto el mismo contenido en informacion.
3-cuando ya hayas efectuado las pruebas satisfactoriamente con archivos de texto pequeños y luego grandes, puedes empezar a hacer sequimiento con los archivos binarios, ya que es más complejo, porque su seguimiento a travez del compilador, se haria con caracteres ilegibles.
4-Prueba interesante, enviar una imagen en formato bmp, primero la envias completa , y al llegar se debe ver OK y el tamaño debe ser identico al de la original.
5-enviar la misma imagen, pero solo la mitad, si todo estabien debe llegar una imagen de exactamente la mitad de la original, y se debe ver absolutamente legible hata la mitad y en el resto un cuadro de color gris o negro o incluso blanco.

Espero que estos consejos te hayan sido de ayuda.

Juank

1- lo del buffer , es simple te dije que de tres veces el tamaño del buffer  es porque por lo general, o almenos en los programas que he hecho, la rutina del primer paquete es difrerente de la del ultimo y estos a su vez se envian con rutinas diferentes a la de todos los paquetes intermedios, es cuestion de  faciliatar el seguimiento, nunca dije que el cliente debeira recibir un buffer mayor...NOOOOOOOOO debe ser igual, sino seria un error garrafal...
2-en efecto si se transmiten 1 y 0 pero si es muy imporante porque si, por ejemplo, el disco esta particionado en segmentos de 512K y tu buffer es de 1K(por ejemplo), estas haciendo 512 envios y la cabeza de escritura en disco bajara una sola vez... asi que mejor enviarias en ese caso un buffer de 512K de una vez..
Otro ejemplo es que envies un paquete digamos de 1024k y que el disco tenga sectores de 256k, cada vez que envies datos el disco realizara 4 operaciones de escritura en cuatro sectores diferentes, lo cual implica que la cabeza de escritura sea movida 8 veces(si cuentas arriba y abajo)... en un proyecto pequeño esto no importa , pero en poroyectos grandes, esto afectara drasticamente el rendimiento de la maquina.
como standart se suele utilizar un buffer de 512 o de 1024 en discos grandes.
3-
Bueno, el concepto de cliente y servidor es solo en cuanto a la conexion, pero desde un angulo más amplio es diferente, si te fijas siempre existen clientes servidor en ambos extremos, ejemplo:

si subes tu pagina web al servidor web (valga la redundancia) se supone que tu eres el servidor porque tu eres el que esta enviando los archivos, pero luego la pagina web se actualiza y te dice si el envio fue exitoso, pero entonces esta informacion en html fue enviada por el servidor web, que antes era el cliente.. no se si me he hecho entender...,
el caso es que siempre se debe de manejar asi como tu lo quieres hacer, se establece una conexion de doble via.
En lenguajes como java, el solo hecho de crear conexion con sockets  ya crea dos conecciones de una vez, una de envio y otra de recepcion.

Ahora, es importante que diferencies , porque si lo haces como tu dices sera una conexion peer to peer y no cliente servidor, y esto implicaria que los usuarios superian siempre el destino ip de las personas con las que se quieren conectar, sin contar que seguramente si el programa esta en un servidor, es mas facil la comunicacion, porque seguramente que el servidor tiene una conexion mucho mejor que que los clientes, asi que creo que seria más rapido enviar al servidor, y que el reenviara al cliente correspondiente, claor que eso depende del tipo de aplicacion.

en cuanto al tamaño del buffer en internet... no se, abria que hacer pruebas.


Juank

No mes has entendido.
1-se debe poeder enviar cualquier archivo,
y segundo lo que te digo es solo para que hagas pruebas de que todo se esta enviando bien:
ejemplo

/*contenido de archivo de texto:*/

envio unoenvio dosenvio tres//hasta aqui nada mas

digamos que tu buffer sea de char buffer[9]
entonces la primera lectura seria

buffer="envio uno"
la segunda
buffer="envio dos"
la tercera
buffer="envio tres"

de este modo, es decir con esta prueba te daras cuenta de que tanto el primero como el ultimo paque estan siendo bien enviados y bien recibidos, la idea es hacer un archivo de pruebas lleno con cosas que te sirvan de informacion para detectar los posibles fallos.. no se si me hecho entender..
cuando yo hacia pruabas tambien enviaba archivos de solo texto porque cada caracter equivale a un byte asi que se puede ser muy preciso en la depuracion.

Juank