From: Joel W. <we...@st...> - 2004-03-29 23:14:23
|
> >>The bad news. Take a look at NetRecv... We check all of the layers one > >>by one. I've fixed things in my version so that we only check a layer > >>if we actually have connections of that type instead of always checking > >>layers like TCPIP and FILE. However, if we have a TCPIP connection > >>active, we will call TCPIPRecv. The problem is that if we don't send > >>data on each tcpip connection (it loops through them all), we sit and > >>wait for the select and transmit timeouts. Am I correct that tcpip is almost certainly going to be the slow connection in any given set? I know it is in our case! If so, maybe the easiest answer is not to change the network layer overall but rather to rewrite the tcpip code so that it doesn't block waiting for a timeout. I'm not good at sockets, but one possibility would be to have a separate thread watch those sockets and maintain a list of new messages; TCPIPRecv would then only have to check to see if that list was non-empty. If tcpip isn't doing the heavy lifting, the extra copies and etc. implied by this approach wouldn't be too great, and the select() would be out of the way of the NetRecv loop. -Joel |