Hacker News new | past | comments | ask | show | jobs | submit login

If so many packets get lost in buffer overflows, can you somehow make the system wait for the buffer to empty?

If sending a packet syncronously, the system call would just hang until the buffers have drained enough.

How would you do it while receiving? Does the outside network just bang bits through the cable like a radio station? Then you'd have no choice but to save everything as fast as it comes in, lest you loose packets. Or is there, deep down on the lowest levels of the stack, actually some kind of request/response going on, even for UDP? For example at the level of Ethernet frames, or even individual bits? Like "here are some bytes. got them? - yes. - here are some more. got them? - (waiiiiting....) yes." Then you could just let the next router in the system wait while you drain your input buffer.

Even if there is no request/response going on, you could still view your incoming as the next routers outgoing. Configure the router to wait with sending until your client has drained the router's output buffer enough. (That would require the router to know how much data you can take.)




> can you somehow make the system wait for the buffer to empty? If sending a packet syncronously, the system call would just hang until the buffers have drained enough.

It sounds like you're trying to make UDP lossless. Use TCP instead.

What if I'm running VOIP? Or a real-time video game? I don't want to wait for the dropped datagram to be received before processing the next one. It's too late! It should have been received already. Skip it and use the next one.

> Does the outside network just bang bits through the cable like a radio station?

Basically, yes. Ethernet has no flow control. IP has no flow control. UDP has no flow control. TCP does.

> is there, deep down on the lowest levels of the stack, actually some kind of request/response going on, even for UDP?

No. Ethernet, as commonly deployed, has no need for this, but CSMA/CD is the retransmit part of the specification in case you are using coax tap or a hub. Each Ethernet frame also has a Frame Check Sequence, and the receiving node will discard the frame if it doesn't match up. It's not up to Ethernet to retransmit. Use TCP for that instead.


> Ethernet has no flow control.

Except it does: https://en.wikipedia.org/wiki/Ethernet_flow_control

Whether people use it or not is another matter!


> Ethernet has no flow control

it has: https://en.wikipedia.org/wiki/Ethernet_flow_control.

edit: formatting




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: