I did read all the data, try it because I did test this many times, and the bug occurs 100% of the time.
you used /sockread -n which will only read the first line from the receive buffer. try this:
on *:udpread:test:{
echo -a * $sock(test).rq
sockread &a
}
if you repeat your tests you will probably notice, as i did, that the event mostly triggers only once with $sock().rq = 10. this implies that both lines are being put into the receive buffer before on UDPREAD has a chance to trigger, and $sock().sport will quite rightly return the address of the sender of the last received datagram.
the issue is why mIRC isn't triggering on UDPREAD fast enough for the scripter to be able to distinguish between two distinct datagrams from two different senders.
No it's not how udp work, thanks god in C you can accuratly get the source ip and port.
i've never used UDP in C so i referred to the Berkeley socket API (on which Winsock is modeled) as in another thread concerning accept() with TCP sockets. and, like that issue, it was revealed that the limitation was inherent to the API rather than mIRC's own implementation:
http://en.wikipedia.org/wiki/Berkely_sockets#Server_2the infinite loop at the end shows that the application is polling the system. i'm not sure if it's sensible to assume that multiple datagrams could be received in between polls - notice how the article prefaces its example with a word of caution as to its reliability in various ways - but it would certainly explain mIRC's behaviour.
EDIT: disregard, this is nonsenseyou could have the clients encode all details that could potentially be lost as the first few bytes of every message.
??
if destination IP address and port is important and is being lost frequently then encode them into the message. a naive way to do this would be to use the first 4 bytes for the IP and the next 2 for the port.
