2

a typical socket program example would be like this:

while(1){
   data = socket.recv()
   //do some work
}

since you don't know when package arrive,it must block to wait until get some data from the listening port,suppose if the program start a heavy work after received the command from another side,during the work , another package arrived,but because at that moment you are doing the work,you are not listening the port, you might missed the package ,no matter how fast you handle the work.

so how does the socket work to handle all the data without any lost?

user207421
  • 305,947
  • 44
  • 307
  • 483
user2003548
  • 4,287
  • 5
  • 24
  • 32

1 Answers1

2

The operating system has a receive buffer which holds packets that have been received from the network but not yet recv()ed by the application. If that buffer fills up packets will be lost. You don't have to be in a recv() call when packets arrive, though you should make sure you call it often enough to keep the buffer from overflowing.

Community
  • 1
  • 1
John Kugelman
  • 349,597
  • 67
  • 533
  • 578
  • This is VERY layman. Packets are lost all the time. A combination of buffers on the network, NIC, OS, and application allow your application to get data from the network when it wasn't specifically looking for it. When data is lost, it is up to the network protocol (sometimes in the low-level protocol (e.g. TCP), sometimes in the application layer) to resend these packets if that is the desired behavior. You're likely working with TCP, which has no visibility into "packets" at the application layer. – xaxxon Aug 19 '13 at 18:35
  • @xaxxon You're right. I've edited my answer to not imply that the receive buffer prevents total protection against packet loss. – John Kugelman Aug 19 '13 at 18:38
  • 2
    If the receive buffer fills up, packets are lost if you are using UDP, but not TCP. In TCP, the receiver acks received data and tells the sender to stop sending new packets if buffer space is not available. On the sending side, TCP resends un-acked packets periodically, and buffers outgoing data and/or blocks the sending code as needed whenever the receiver is not allowing new data to be sent. This is all handled by the TCP stack for you on both ends. Short of any physical network problems, TCP does not lose data, and if it does lose data then the connection needs to be reset anyway. – Remy Lebeau Aug 19 '13 at 20:30
  • @RemyLebeau I assumed the use of `recv` means the OP is using UDP. But you are right. I answered the question directly and very simply. There's certainly a lot more to be said here. I'm surprised nobody's chimed in with a better, more detailed answer! ;-) – John Kugelman Aug 19 '13 at 20:32
  • `recv()` is most commonly used for TCP, but it can also be used for connection-oriented UDP. `recvfrom()` is most commonly used for connection-less UDP, but it can also be used for TCP and connection-oriented UDP. – Remy Lebeau Aug 19 '13 at 22:40
  • @RemyLebeau packets are lost all the time. Since there is no concept of TCP at any "packet" layer (or packets in TCP), your statement makes no sense. The stream of bytes presented to the application is consistent with what was sent, but packets are lost all the time. – xaxxon Aug 20 '13 at 02:56