Reputation:
I have several points regarding .NET socket implementation so I will state them sequentially:
stream
and protocol type:tcp
, when using the method Receive
(which is blocking the process), with a parameter application byte buffer is actually dequeuing the socket buffer in chunks that have the same size of the application byte buffer you declared and defined in your application then assigns this chunk to your application byte buffer you sent to Receive
function.Send
method of a socket sends the the data to the end point connected host Socket buffer and not application buffer.Accept
is non-blocking, a thread is created for it in the underlying implementation, and it has a queue of its own that is dequeued when Accept
method is called.I ask all of this to check if my understanding so far is right, or if it's mostly wrong and need correcting.
Upvotes: 0
Views: 172
Reputation: 7452
First of all .net's implementation is mostly just a managed wrapper around winsock.
My understanding is that an instance of a Socket has a buffer of a changeable size in its internal class implementation, and is actually a queue of bytes, and also is different than the application buffer that you declare and define in your application.
Ok so far.
In synchronous mode using socket type: ... when using the method Receive
When you call Receive, data will be copied into the supplied buffer and the number of bytes written will be returned. This may well be less than the size of the buffer. If your buffer is not large enough to accomodate all of the data queued by the TCP stack only as many bytes as can be copied into your buffer will be copied, the remaining bytes will be returned on your next call to Receive.
Sockets treat all data sent (or received) as being a continuous stream without breaks. However, data sent across the network is subject to networks or hosts splitting the data to meet constraints like a maximum packet size. Your code should assumes data may arrive in arbitrarily sized chunks. Incidentally, this kind of message is more likely to appear in a production environment than in a development/testing one.
socket sends the the data to the end point connected host Socket buffer and not application buffer
Send will return when the data is queued by the TCP stack. If the TCP window is full and the remote endpoint is not reading off the socket (say because it is waiting for its own send to complete) this could potentially be a long time.
Finally, since the Socket method Accept is non-blocking
Per the documentation, Accept will either block until a connection is received or (in non-blocking mode) either synchronously accept the first available connection or throw if no connection is available.
this is still relevant and would still be recommended reading for anyone about to start writing network code.
Upvotes: 1