Hmmm...that doesn't look like it will work. Last night I wanted to make sure everything was being read in the binvar so I changed the sockread to read 8192 bytes and compared how much was being queued to how much was read. It still came out to 2 sockreads
But thanks for the suggestion...at least one brave soul replyed :tongue:
Picture this...You are sending data on the network. The server sends you a command...this command needs to be read as a whole. But the data doesn't fit all into one packet. It spans 4 of them. A buffer is created to hold all of this data. When the last packet for that command is recieved...in the packet its self the PSH flag is set and all the queued data is sent to the app.
Well that is the way its suppose to work...in mIRC it seems that when the push flag is set the data is sent but it doesn't add that lasts packets data to the buffer.
<part of a rfc>
The discussion in RFC-793 on pages 48, 50, and 74 erroneously implies that a received PSH flag must be passed to the application layer. Passing a received PSH flag to the application layer is now OPTIONAL
At the receiver, the PSH bit forces buffered data to be delivered to the application (even if less than a full buffer has been received). Conversely, the lack of a PSH bit can be used to avoid unnecessary wakeup calls to the application process; this can be an important performance optimization for large timesharing hosts. Passing the PSH bit to the receiving application allows an analogous optimization within the application.
</part of a rfc>
Blah...well anyways its not that big of a deal. But mIRC should work that way. I can script around it though just like I do for many other things
hehe...I'm going to be trying one other thing before I move on and see if the symptoms are the same.
