< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

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.