> I have an application that uses IOCP. Thanks in great part to the folks on this > list, it has been working very well. I connect to multiple devices and receive > the data from them with no problem. At this point, the need has been only to > monitor the data sent from these devices ( once per second). A modification in > the specs now requires that the application send data to these devices. This > sending of data is totally asynchronous with regard to the receiving of > information. I have a structure derived from OVERLAPPED that I use to manage > the receive buffer and that is used in conjunction with the IOCP to tell me > from which device the information is coming. When I am preparing to use > WSASend, do I need to allocate a separate OVERLAPPED struct or can I use the > existing one by adding a send buffer to my already present receive buffer?
*Every IO* should have it's own overlapped. Not just one overlapped for all writes and one overlapped for all reads. You probably already knew this, but just in case. :-) For the writes you can use the same outbound buffer if you are sending the same data to all the sockets. In your overlapped derived instances have them use all the same buffer object and increment it's counter once for each write, then do your writes, as each write completes decrement the counter (wrapped by a crit section), upon zero, free the write buffer object. Of course this doesn't work for reads because you'd have all the sockets overwriting the same buffer. While I'm at it, another "trick" is *don't* keep track of any outstanding IOs. You won't need to. When you close the socket (or it closes from the other end or from network failure) all the outstanding IOs will hit the IOCP queue as errors, giving you the chance to clean them up. Keeping track of all of them is a waste of your coding time and your system's memory. /dev _______________________________________________ msvc mailing list [EMAIL PROTECTED] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
