I can’t speak as to ‘kernel sockets’ but asynchrous I/O is the only sane
way to manage user-level socket programming. I use the MFC CAsyncSocket
class. This has specified event callbacks, so the way you do a send is to
call the send method. This will return either a negative value (an error
code) or a non-negative value (the number of bytes sent). You use this
value to track the buffer. Suppose your buffer is 1000 bytes. You do a
send of 1000 bytes, it sends 100. So you keep 900 bytes around, until you
get a “send” notification. Then you send the 900-byte buffer. It sends
200 byes, so you keep 700. Repeat until bytes-to-send goes to 0. This is
not “special” code; this is plain-vanilla asynchronous socket programming,
so I have no idea why you would think it is somehow “special”.
TCP protocol guarantees that the packets will arrive in the correct order,
and I don’t see why the receiving end needs to “serialize” send calls;
certainly there is no need yo “serialize” the on the sending side, unless
you are referring to the quite ordinary
don’t-send-until-you-get-a-ready-to-send-notification model, which is not
“special” code but very, very ordinary asynch socket programming.
It would make no sense to do network transmissions from multiple
independet threads; to the best of my knowledge, there is no guarantee
that transmissions would not be interlaced in unpredictable ways even if
you are using synchronous sockets. MFC solves this problem by simply not
supporting multithreaded use of sockets; only one thread at a time can
“own” a socket. So if I am doing asynchronous socket programming, I
either do it from the main GUI thread (because it doesn’t block the
thread) or use a dedicated thread for the purpose.
Microsoft used to have an MSDN article about multithreaded socket
programming; the only thing wrong with it was that it got socket
programming wrong, multithreading wrong, and synchronization wrong. One
of my clients called me in to fix their product about two years into its
development, and (I found out later) their programmer had built the entire
system on this horrible example. I told them that there was nothing wrong
with their product that a total rewrite could not fix, and they pulled the
plug on it after having spent over a half-million dollars on its
development. I rewrote the Microsoft example code, salvaging practically
nothing, and you can find the article on www.flounder.com/mvp_tips.htm,
search for asynchronous.
You should not expect multithreaded socket sends to arrive in the correct
sequence; that may be an accident of one particular version of the OS
socket support. To implement this correctly requires writing code that
limits the use of the socket to a single thread. Fortunately, this is
trivial to accomplish.
joe
Hi experts,
I would like to further understand the behavior of the windows kernel
socket with regards to asynchronous sends over TCP.
From my experience with BSD sockets, non-blocking sends can issue less
bytes than what was requested, and thus I need to have special code that
monitors how much was sent and repeatedly send what was left. This also
means that to have meaningful results on the receiving end, one must
serialize all send calls.
Now the NT kernel sockets give us asynchronous ability. However, I won’t
be able to issue multiple asynchronous sends (from multiple threads or
from one thread) if partial sends are possible since then the receiving
end might get mixed messages.
My question is: Is it possible to have partial sends with NT kernel
sockets, and if it is not possible, is it allowed to issue multiple sends
concurrent sends and expect that the send messages won’t mix in the TCP
stream. For example, if one message is AAAA, and the other is BBBB, I
don’t want AABBAABB but AAAABBBB and BBBBAAAA are totally acceptable.
Many thanks,
Eran.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer