Socket read problems

[Len Morgan]

  Dar,

I wish it was that simple but the length of the message is only in one 
byte so it's pretty hard to swap.  For test purposes, I have scrolling 
field where I print the progress of the conversation and I am displaying 
the correct length.  Also, I've got WireShark on the line so I can look 
at the actual packets to make sure I'm picking the right bytes, etc. and 
all of that is ok.  The only thing that seems "out of place" is that 
there is one more zero byte at the end of payload that fills out the 
data area to an even word boundry.  This null byte is not part of the 
data and is not counted in the length byte that I'm reading.  I believe 
that is part of the TCP/IP spec but it's been a long time since I've 
done a digital colonoscopy on network protocols so I could be mistaken.

What ends up happening is that the socket read command is getting one 
more byte than I've asked for so I'm wondering if it hangs up when I try 
and close the socket since I still have one unread byte in the buffer.  
As it turns out, if I try and read that extra byte too, the result is 
the same:  The read command will not finish until 
<socketTimeoutInterval> milliseconds have passed yet is never sends me a 
socketTimeout message.

The particular slave I'm talking to is from a major commercial vendor 
(inventor of ModBus as a matter of fact) but as I recall, my own slave 
(built with an Arduino) suffered the same "problem."

Is it possible that since I'm not using the callback on the read 
complete, that there is a bug in the read socket library?  I will do 
some more experimentation today and report back what I find.  I will 
also try and whip out a LiveCode slave and see if I can make it do the 
same thing on the same machine.  That should be interesting.

len morgan


On 10/8/2010 12:42 AM, Dar Scott wrote:
> Could you have gotten the two length bytes swapped and are asking for 
> way too many bytes?
>
> Dar Scott
>
> On Oct 7, 2010, at 6:22 PM, Len Morgan wrote:
>
>>  I'm trying to read data from a MODBus/TCP controller and having some 
>> issues with the timing of the read command.  I request a block of 
>> registers from the slave and it returns the requested bytes and 
>> header just fine and very quickly.  In order to read everything 
>> right, I have to first read the first 6 bytes of the header to know 
>> how many bytes are to follow.  Once I know that, I do a read from 
>> socket tSock for <bytes> characters.  Note that ALL of the characters 
>> have been received in a single packet so once I read the 6 bytes, the 
>> rest of the data is already in the socket buffer.
>>
>> The problem I have is when I do the second read, the read command 
>> blocks for the socketTimeoutInterval before continuing.  It doesn't 
>> matter what I set it to, it will wait that long before continuing.  I 
>> tried catching the socketTimeout message but that message is never 
>> sent, even when I set the socketTimeoutInterval to 5 milliseconds!
>>
>> I am not using the read ... with message form of the command since I 
>> want the handler to wait until all the bytes have been received 
>> before I move on.  Has anyone else seen this?  Have I missed 
>> something in the documentation or could this be something in the 
>> Windows code that handles sockets?
>>
>> Any help would be appreciated!
>>
>> len morgan
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>