3

Say I have a server that listen's on Port X.

Several client's are connected to the server and send data via the send command.

What happens if the server does NOT have a recv routine to "flush" the buffer?

Does the buffer reside in your own process or in Windows?

Is it also possible to "DDos" still?

Ben
  • 3,380
  • 2
  • 44
  • 98

2 Answers2

4

What happens if the server does NOT have a recv routine to "flush" the buffer?

The receive buffer that corresponds to this socket will fill up. When that has happened, UDP will silently discard incoming datagrams. TCP will discard incoming datagrams and not acknowledge them, triggering congestion control (halving the window size under Reno/XP or switching to the delay-window under CompoundTCP/Vista+).
When you remove some data from the buffer, UDP will resume accepting datagrams as if nothing had happened (it's your problem to figure out that you lost data!), and TCP will continue accepting and acknowledging packets, gradually increasing the window size again (data in the simulated stream will be consistent as if nothing was dropped, ever).

Does the buffer reside in your own process or in Windows?

It could be both, there is no urgent requirement for either, as long as it is managed/owned by the library layer it could as well reside in user space (though it's practically in kernel space). This is a detail that isn't important though, since you have no way of directly accessing the raw buffer either way. You can only access it via the API provided by your networking library (either Winsock functions or Berkeley-like socket functions).

Is it also possible to "DDos" still?

Yes. A DDoS is an attack that physically saturates the network cable. It does not matter a lot (or, at all) what you do on the software side. A DDoS needs to be addressed at a higher network layer (one that you usually don't have access to!). Once the rogue traffic made it past the "fat pipes" onto your server's subnet (or onto the router connecting it upstream), there is nothing more you can do.
Networks come in different physical (optical or electric) and logical (e.g. token) flavors, but in either case, there can only be one sender at any time on the cable. If someone saturates your line's capacity with a DDoS, neither you nor the router will be able to put packets on the wire, except occasionally, by chance. Routers, however, are built to have short forward queues and discard packets quickly when the queue fills up, so practically you're out of luck.

Damon
  • 67,688
  • 20
  • 135
  • 185
  • 1
    Congestion control has nothing to do with it. The receiver advertises a zero receive window, which obliges the sender to stop sending. Congestion control comes into play when data isn't acknowledged at all. – user207421 May 28 '14 at 22:13
  • 1
    @EJP: That is nonsense. The receiver advertises **nothing** if you decide not to call `recv` at some point. It simply does not do anything when the buffer is full, including ACKing any incoming datagrams (i.e. data is not being ACKed at all). Exactly as I've written. The receive window may be or may not be zero (it will be if, _and only if_, you have _never_ received anything), but that's irrelevant. It's only about the same thing happening sooner or later. – Damon May 29 '14 at 18:50
  • does this mean that if i have a ssh server, and a software foo that receive data but never `recv` , my NIC buffers will finished by being full of packet from my software foo, and i will not be able to ssh anymore ? – allan.simon Oct 23 '16 at 19:49
  • @allan.simon: No, each socket has a separate receive buffer. Otherwise, that would be quite bad, wouldn't it -- one hung program would stall every other program using the network. A different SSH connection goes via a different socket, so there's no interference. – Damon Oct 23 '16 at 20:50
  • @Damon, thanks I was thinking it was only at the kernel level that there was such a separation of buffer, but yeah now that I think about it, the NIC can separate by introspecting the port – allan.simon Oct 23 '16 at 21:05
1

I don't have a very thorough understanding of TCP, so this layman's explanation may not be entirely correct. Relevant search terms to learn more are "flow control", "window", "throughput" and "saturation".

See what happens when tcp/udp server is publishing faster than client is consuming?, where the answer says "it won't": a connection allows only for a certain amount of data to be "in flight" and stop sending once it detects that maximum has been reached.

When all receive buffers (NIC, kernel) are full and not being processed by the receiving application, and the sender keeps sending data (maliciously not adhering to the TCP protocol), the receiving NIC will drop the incoming packets.

This will still cost bandwidth as the packets end up in the NIC, so yes, that is still a DDOS vulnerability.

Community
  • 1
  • 1
CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • So the TCP packet (content only!) is buffered in the NIC and not buffered in the Application Layer at all?! – Ben May 28 '14 at 13:40
  • 1
    Well you say your application is not calling `recv()`, so how would the received data end up in the application? Data goes NIC -> kernel -> application, and if the last step doesn't happen, data happily sits in the former two. – CodeCaster May 28 '14 at 13:41
  • 1
    @BenjaminWeiss: No, as the answer already states there may be kernel receive buffers. – MSalters May 28 '14 at 13:42
  • 1
    Please don't accept this answer right now, I'm sure someone more knowledgeable can shed a more in-depth light on this. And yes, the kernel is a part of an OS. Read [Wiki: Kernel (computing)](http://en.wikipedia.org/wiki/Kernel_(computing)), [Doubt regarding Winsock Kernel Buffer and Nagle algorithm](http://stackoverflow.com/questions/1017507/doubt-regarding-winsock-kernel-buffer-and-nagle-algorithm). – CodeCaster May 28 '14 at 13:45
  • I am sure you are right. But let's wait for a little bit. Thank you for the contribution. – Ben May 28 '14 at 13:49