Socket read problems

[Alex Tweedly]

  No good suggestion - but you might try multiple reads, each of one 
byte to see how many you get.

-- Alex.

On 08/10/2010 12:29, Len Morgan wrote:
>  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
>>
>>
>
> _______________________________________________
> 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
>