¿cuál es la diferencia entre read() y recv(), y entre send() y write() en la programación de socket? rendimiento y velocidad y otro comportamiento.¿Cuál es la diferencia entre read() y recv(), y entre send() y write()?
La única diferencia es que recv/send le permite especificar ciertas opciones para la operación real. lectura/escritura son las funciones del descriptor de archivo 'universal' mientras que recv/send son un poco más especializadas (por ejemplo, puede establecer un indicador para ignorar SIGPIPE, o para enviar mensajes fuera de banda ...).
Esto es incorrecto, hay otra diferencia en el caso de los datagramas de longitud 0 - Si un datagrama de longitud cero está pendiente, lea (2) y recv() con un indicadores argumento de cero proporcionan un comportamiento diferente. En esta circunstancia, leído (2) no tiene ningún efecto (el datagrama permanece pendiente), mientras que recv() consume el datagrama pendiente. –
@AbhinavGauniyal ¿Cómo proporcionaría eso un comportamiento diferente?Si hay un datagrama de 0 bytes, ambos, 'recv' y' read' no entregarán datos a la persona que llama, pero tampoco ningún error. Para quien llama, el comportamiento es el mismo. Es posible que la persona que llama no sepa nada acerca de los datagramas (puede no saber que se trata de un socket y no de un archivo, es posible que no sepa que se trata de un socket de datagrama y no de un socket de transmisión). Que el datagrama permanezca pendiente es conocimiento implícito sobre cómo las pilas IP funcionan en kernels y no son visibles para la persona que llama. Desde la perspectiva de la persona que llama, todavía proporcionarán un comportamiento igual. – Mecki
@Mecki eso no es conocimiento implícito para todos, tómenme por ejemplo :) –
"Rendimiento y velocidad"? ¿No es ese tipo de ... sinónimos, aquí?
De todos modos, la llamada recv() lleva banderas que read() no hace, lo que lo hace más poderoso, o al menos más conveniente. Esa es una diferencia. No creo que haya una diferencia significativa en el rendimiento, pero no lo he probado.
Tal vez no tener que lidiar con banderas se pueda percibir como más conveniente. – semaj
read() es equivalente a recv() con un parámetro banderas de 0. Otros valores para el parámetro banderas cambiar el comportamiento de recv(). Del mismo modo, write() es equivalente a send() con flags == 0.
Esta no es toda la historia. 'recv' solo se puede usar en un socket, y producirá un error si intentas usarlo, digamos,' STDIN_FILENO'. –
Este hilo ahora es el primer golpe en Google, Google ama stackoverflow – Eloff
read() y write() son más genéricos, funcionan con cualquier descriptor de archivo. Sin embargo, no funcionarán en Windows.
Puede pasar opciones adicionales a send() y recv(), por lo que puede tener que utilizarlas en algunos casos.
acabo de notar recientemente que cuando utilicé write() en un socket en Windows, que funciona casi (FD pasó a write() no es el mismo que el que pasó a send(); utilicé _open_osfhandle() para conseguir el FD para pasar a write()). Sin embargo, no funcionó cuando traté de enviar datos binarios que incluían el carácter 10. write() insertaba en algún lugar el carácter 13 antes de esto. Cambiarlo a send() con un parámetro de indicadores de 0 solucionó ese problema. read() podría tener el problema inverso si 13-10 son consecutivos en los datos binarios, pero no lo he probado. Pero eso parece ser otra diferencia posible entre send() y write().
+1. Ver también [winsock no admite lectura/escritura] (http://stackoverflow.com/q/4778043) –
Otra cosa en Linux es:
send no permite operar en fd no zócalo. Por lo tanto, por ejemplo para escribir en el puerto usb, es necesario write.
Piense en escribir como implementado así: '#define write (...) send (## __ VA_ARGS__, 0)'. – carefulnow1