Calling WSAEventSelect() causes the event to become signalled
even if there is nothing new, probably due to the socket being
writable.
Due to this, io_peer_recv() signals the event object whenever
claiming recv_busy just to check for pending data, and again
when releasing it, which leads to another worker immediately
waking up and claiming it to check for new messages, starting
the cycle again.
Only claim recv_busy and mask FD_RECV events if some data is
actually read from the socket.
The documentation for IDirectPlay8Peer::SendTo() makes no
mention of message size limits, so this may need more attention
if games are sending even bigger messages to each other.
Clearing FD_RECV and FD_CLOSE from the event flags when processing a
recv() event will prevent the other worker threads associated with that
socket from waking up repeatedly, checking recv_busy, then sleeping
without having done anything, wasting time and potentially preventing
them from servicing their other sockets.
- IDirectPlay8Peer::EnumHosts() requires a device address to specify
the service provider to emulate.
- IDirectPlay8Peer::EnumHosts() allows overriding the address/port
that discovery messages are sent to.
- IDirectPlay8Peer::Host() requires at least one address. Addresses
with different service providers are not supported yet.
- Implement IDirectPlay8Peer::GetPeerAddress() method.
- Populate pAddressSender in DPNMSG_ENUM_HOSTS_QUERY message.
- Popupate pAddressPlayer in DPNMSG_INDICATE_CONNECT message.
- Base host addresses created by IDirectPlay8Peer on service provider
of device address given to Host() method.
The threading model used for processing messages here will need
redesigning; we can't allow the application to block the event loop
when processing a message in case it calls something which won't
return until a message is processed.
Final model will probably use a pool of workers which will handle I/O
one-at-a-time, blocking and allowing other threads to deal with the
I/O when in the application message callback.
The protocol is going to use TLV messages, containing zero or more
fields represented using the same TLV header. Functions for
(de)serialising DirectPlay message structures will be built on top of
these classes.
