Re^6: deal data transfer

[xiaoyafeng]

eh, well, I thought whatever protocol the program runs over, the basic procedure would be the same, listen the port, receive request, fetch data somewhere, pack etc. Maybe I was wrong. any suggestions if protocol is IEC 101?

[BrowserUk]

In general, when looking to try and help someone, it is easier to read actual documentation, than go through an extended question and answer trying to tie down the details.

Questions like: are the numeric values little or big-endian; how are the checksums calculated; are the packets fixed or variable length; if variable, are they length prefixed or post-delimited; etc. All of this is clear from the documentation.

Which brings me to the question: what is it that you are really asking for help with? What is it that you are having trouble doing?

[xiaoyafeng]

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:

1. read 4bytes to know size of packet, reset length parameter, read rest of it and check end char and checksums
2. 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.

[BrowserUk]

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.

1. First you need to read 1 byte to determine if it is a fixed (0x10) or variable (0x68) length packet.
2. If the former, you can then read the next 5 bytes, check the checksum and unpack the payload.
3. If the latter, then you need to read the next two bytes to obtain the length.
4. Then you add 3 to that. (To account for the second start byte, the checksum and stop bytes.)
5. Then you can read the rest of the packet, check the sum and unpack the payload.
6. 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.