30-01-2008, 05:33 AM
Actually, it is a bit more complicated than that. Although VB6 applications are single-threaded, this does not mean VB6 applications use one thread. A send operation is like a file write - you only need to know that it will be written, not that it is written. I am not saying this is how it is done - I am not sure exactly - but it would not be surprising if a Winsock send is completed upon not the data being sent but the data being written to the socket output buffer. In fact, it is likely this is the case, or close to it, since the socket will queue packets if Nagling is enabled without blocking the process until they are sent. The socket wont be able to be written to directly after you finish your last write, it still may have extra processing to do on the packet which could increase the block time on the next send if it is still in this "finalizing" state.
So using multiple sockets, you can basically get a very cheap, very poor usage of the system thread pool to output very minimal work to foreign threads. Though, theres probably next to no benefit of doing this when it can be all thrown into the same control since it just gives the OS the more work in the end unless the sockets are bound to different addresses or using different protocols.
So using multiple sockets, you can basically get a very cheap, very poor usage of the system thread pool to output very minimal work to foreign threads. Though, theres probably next to no benefit of doing this when it can be all thrown into the same control since it just gives the OS the more work in the end unless the sockets are bound to different addresses or using different protocols.