Re^8: deal data transfer

Thanks! BrowserUk. Actually I have no any idea about data transfer in perl. Now first thing I'm a little confused is how to check a variable length data packet correctly. It seems I can use 2 ways below to treat it:

read 4bytes to know size of packet, reset length parameter, read rest of it and check end char and checksums
read data in a loop, if there is no any data received in a time (e.g 3 sec) or read function return 0, check if last 2 bytes are correct checksum and end char.

So am I on the right way? Which way above is better or correct? Is there any codes in modern perl about data transit in network or serial for reference? Please help

Again, apologies for my poor english I hope i express my question clear enough.

I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

Comment on Re^8: deal data transfer

Replies are listed 'Best First'.
Re^9: deal data transfer by BrowserUk (Patriarch) on May 18, 2011 at 08:56 UTC
It seems I can use 2 ways below to treat it: Looking at the protocol, (which is pretty badly designed IMO), you're going to have to use a mixture of both methods. First you need to read 1 byte to determine if it is a fixed (0x10) or variable (0x68) length packet. If the former, you can then read the next 5 bytes, check the checksum and unpack the payload. If the latter, then you need to read the next two bytes to obtain the length. Then you add 3 to that. (To account for the second start byte, the checksum and stop bytes.) Then you can read the rest of the packet, check the sum and unpack the payload. And finally ack (0xe6) or nack (0xa2) the packet. Don't forget to binmode your socket and use sysread. I've found that wrapping sysread in a sub that checks the return code and returns the result for assignment makes life much easier. That still leaves the problem of timeouts. There are various ways of tackling that--alarm, ioctl, select etc. Which is appropriate will depend a lot on you platform. That said, tcpip comms is pretty reliable especially if LAN connected. It may be a sufficiently infrequent occurrence that you can essentially ignore it. That will depend upon your circumstances and network. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]

Replies are listed 'Best First'.

Re^9: deal data transfer
by BrowserUk (Patriarch) on May 18, 2011 at 08:56 UTC

It seems I can use 2 ways below to treat it:

Looking at the protocol, (which is pretty badly designed IMO), you're going to have to use a mixture of both methods.

First you need to read 1 byte to determine if it is a fixed (0x10) or variable (0x68) length packet.
If the former, you can then read the next 5 bytes, check the checksum and unpack the payload.
If the latter, then you need to read the next two bytes to obtain the length.
Then you add 3 to that. (To account for the second start byte, the checksum and stop bytes.)
Then you can read the rest of the packet, check the sum and unpack the payload.
And finally ack (0xe6) or nack (0xa2) the packet.

Don't forget to binmode your socket and use sysread. I've found that wrapping sysread in a sub that checks the return code and returns the result for assignment makes life much easier.

That still leaves the problem of timeouts. There are various ways of tackling that--alarm, ioctl, select etc. Which is appropriate will depend a lot on you platform. That said, tcpip comms is pretty reliable especially if LAN connected. It may be a sufficiently infrequent occurrence that you can essentially ignore it. That will depend upon your circumstances and network.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]