This is the intended and expected behaviour and applies to older versions of mIRC as well.
This issue may be more apparent in newer versions of mIRC due to a few changes to how sockets are handled, however it is in fact present in all versions of mIRC.
Sockets are asynchronous, which means that they send data in the background when they can. There is no guarantee that data can be sent immediately in Windows sockets. An attempt to send data may in fact block, or send only partial data, in which case mIRC will try to send any remaining data when Windows indicates it is ready for more.
When using sockets, you should never assume that you can close a socket immediately after sending data. You should wait until on SOCKWRITE has triggered, as described in the help file, and check the send queue to see if it is empty before closing the socket.
Hi Khaled, thanks for looking into this however, I already mentioned that queueing was working in older versions but it was still sent instantly if nothing was in the queue, why doesn't 7.xx do this? Surely if nothing is in the queue then it should send when it is called?
And using the sockwrite event I cannot see what was actually wrote to the socket, therefore I cannot perform specific actions based on what was sent plus this would double the size of a script because I will be checking what needs to be sent and then checking it again once it has been sent and performing the necessary
edit: also why are all sockets treated as asynchronous? UDP sockets are asynchronous where as TCP should be synchronous because both sides need to make acknowledgements?
