Socket read problems
alex at tweedly.net
Fri Oct 8 09:01:57 CDT 2010
No good suggestion - but you might try multiple reads, each of one
byte to see how many you get.
On 08/10/2010 12:29, Len Morgan wrote:
> 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:
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode