RE: [reSIProcate] TCP Behavior - on Windows at least...
OK - It turns out, that it had nothing to do with Windows. It was my own
lack of understanding...
I was wrong about my assumptions on how buildFdSet/select/process works. I
didn't realize that select adjusts the FdSet's you pass in, and returns the
signaled sockets only. After coming to that revelation - I realized that in
my apps main loop, I was skipping the select call if
getTimeTillNextProcessMs returned 0, thus sometimes the call to
stack->process(fdset) was made with the original fdset returned from
buildFdSet. This will cause some obvious badness - ie. Sockets appearing
signaled that are not really signaled.
Thanks for all your help!
I think the following comments still apply though:
Let's say we unblock from select because there is data to read on one of
many TCP connections. When we call process on the TCP Transport and
ProcessSomeReads get's called - there is no guarantee that we will actually
try to read from the same connection/socket that triggered the select. This
means the entire process call could No Op. Then we need go through
BuildFdSet/select/process again, this time hopefully the connection manager
will return the right connection (it uses round robin reading). This doesn't
seem right - is this the way it was intended to work? It seems incredibly
inefficient when there are lots of TCP connections. It would be good if the
Connection Manager could actually return a connection that has data waiting.