mIRC Home    About    Download    Register    News    Help

Print Thread
#29684 14/06/03 02:49 AM
Joined: Jun 2003
Posts: 6
K
kovert Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
K
Joined: Jun 2003
Posts: 6
First off I'm not sure if this is a bug...or the way its suppose to work...but it is a problem in my script.

I'm reading data from a socket into a binvar the problem is when the data spans multiple frames...yes we are talking about network traffic. Down below is TCP traffic on the network...

Direction Flags Length Seq Ack
Server -> ME ACK 1360 Seq=2341 Ack=1250
ME -> Server ACK 0 Seq=1250 Ack=2359
Server -> ME ACK 1360 Seq=2359 Ack=1250
Server -> ME ACK 1360 Seq=2373 Ack=1250
ME -> Server ACK 0 Seq=1250 Ack=2389
Server -> ME ACK, PSH 46 Seq=2389 Ack=1250
ME -> Server ACK 0 Seq=1250 Ack=2394

If data is to big to fit into one frame it is broken into multiple frames. All of the data is read into a buffer and the push flag tells the reciever to send the buffer to the application.

In mirc scripting I would see 2 sockreads
4080 bytes
46 bytes

It is to my understanding that the sockread should have read all 4126 bytes. Or am I just a retard laugh

I would like to know if this is something that mirc is doing or if its the way it is suppose to work? Can anyone with TCP experience or knows a great deal about TCP help me out? Oh...my OS is win XP pro.

#29685 14/06/03 04:19 AM
Joined: Jan 2003
Posts: 3,012
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
/sockread -f 4126 &binvar ?


-KingTomato
#29686 15/06/03 12:19 AM
Joined: Jun 2003
Posts: 6
K
kovert Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
K
Joined: Jun 2003
Posts: 6
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 frown 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 frown hehe...I'm going to be trying one other thing before I move on and see if the symptoms are the same.

#29687 15/06/03 01:07 AM
Joined: Jan 2003
Posts: 3,012
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
Code:
on 1:SOCKWRITE:mysocket: {
  if ($sockerr) /echo -a Error
  else {
    ; .yourcodehere

    ...

     if ($isfile(data.txt)) .remove data.txt
  }
}

on 1:SOCKREAD:mycoket: {
  /sockread -f &amp;data
  /bwrite data.txt -1 -1 &amp;data
}

on 1:SOCKCLOSE:mysocket: {
  /bread data.txt 0 $file(data.txt).size &amp;data
  .remove data.txt

  ...

  ; parse the file here, do what youw ant with it.  The whole packet is now in the &amp;data binvar
} 


-KingTomato
#29688 15/06/03 01:35 AM
Joined: Jun 2003
Posts: 6
K
kovert Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
K
Joined: Jun 2003
Posts: 6
Ah yes that would work cept the connection to the server does not close. In fact it needs to stay open! So that I can receive more commands...

I plan on trying one other thing...to see if I get 2 sockreads still. Then I plan on adding some code that will append the extra data to the binvar if a varible is set and if it fails error checking. Because all of the data could fit in one sockread sometimes...and sometimes not. If it fits into one sockread that var will be set but the error checking should not fail so it will not append it. At least this is the only known spot that this could happen at. The rest of the time everything works as planned. Most of the commands don't take up more than one sockread.

Thanks for the support though!

Last edited by kovert; 15/06/03 01:37 AM.
#29689 15/06/03 05:26 AM
Joined: Jun 2003
Posts: 6
K
kovert Offline OP
Nutrimatic drinks dispenser
OP Offline
Nutrimatic drinks dispenser
K
Joined: Jun 2003
Posts: 6
I changed how much the server was sending to me...sometimes mirc reads it all in one sockread sometimes it doesn't. I'm not sure why...

#29690 16/06/03 03:43 AM
Joined: Jan 2003
Posts: 3,012
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2003
Posts: 3,012
Still do as planned. Save to a text file, and reference the size of the file. When it hits N bytes, then parse it..

on 1:SOCKREAD:mysopcket: {
/bread -f &binvar
/bwrite data.txt -1 -1 &binvar

if ($file(data.txt).size == 4126) {
/bread data.txt 0 4196 &data

...parse...

.remove data.txt
}
}


-KingTomato

Link Copied to Clipboard