deal data transfer

xiaoyafeng has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks

I've been writing a client to charge data transfer as a private protocol like

start char  68H    68
length  L    15
length  L    15
start char  68H    68
domain  C    73
address  A  (little byte)    01
address  A  (high byte)    00
data    Е
ЕЕ    Е
data    Е
check sum    03
end char 16H    16
[download]

Since I have no any experience in binary data transfer, I'd like to ask monks to provide me with some codes/modules about this. BTW, looks many factors need to be considered, checksum, length, etc. how hor~

TIA, any replies are appreciated!

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 deal data transfer Download Code

Replies are listed 'Best First'.
Re: deal data transfer by John M. Dlugosz (Monsignor) on May 17, 2011 at 09:56 UTC
I've processed binary data streams in Perl using `pack` and `unpack`, working from an existing definition. To design your own binary protocol, start with a list of requirements. Like, why does it have to be "binary"? In one case of mine, it was intended to be small. Or perhaps it needs to be able to update-in-place in a file? In any case, list those issues first. Then I'll be happy to discuss with you more.	[reply] [d/l] [select]
Re^2: deal data transfer by xiaoyafeng (Deacon) on May 18, 2011 at 01:51 UTC
Hi, John M. Dlugosz Thanks for your help! here I elaborate my question. First, the prog I intend to finish is to provide data to remote server. Data transfer could be by ethternet, serial etc. Second, whatever way of transfer, the process runs over a request-answer-mode protocol which is defined by server side and exist already. it's like `Send:(data request packet) 68 15 15 68 73 01 00 78 01 06 01 00 0B 01 05 19 0B CA 03 06 1E 0B +CA 03 06 03 16 Receive:(confirm) E5 Step 2: Send :(request data) 10 5A 01 00 5B 16 Receive :(data) 68 15 15 68 28 01 00 78 01 07 01 00 0B 01 05 19 0B CA 03 06 1E 0B +CA 03 06 B9 16 as I mentioned in this thread before, every byte has its own meaning d +efined by protocol, e.g. length of data, checksum, end flag.` [download] Third, I've had some experience about pack/unpack, but I've stuck most because I feel like many details about implementation of this protocol is ahead. like, How can I assert the data packet send from server is finished? because the size of data packet is variable by waiting time or check the end char? How check checksum? if the data packet is broken, how can I treat this session? close this session or wait the next packet? ... Since I have no any experience about this, I have many questiones to be insighted. Before I indulge into the similar impleation in C, I'd like to know if there is relative mature implementation in perl. I hope gurus here could help me out! Thanks! I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction	[reply] [d/l]
Re^3: deal data transfer by BrowserUk (Patriarch) on May 18, 2011 at 03:02 UTC
Are you wanting to talk to a Beckhoff twincat? 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]
Re^4: deal data transfer by xiaoyafeng (Deacon) on May 18, 2011 at 03:06 UTC
Re^5: deal data transfer by BrowserUk (Patriarch) on May 18, 2011 at 03:09 UTC
Some notes below your chosen depth have not been shown here
Re^3: deal data transfer by John M. Dlugosz (Monsignor) on May 18, 2011 at 12:01 UTC
Maybe I misunderstood: you are not trying to design or invent a protocol, you are trying to write Perl code that uses a protocol that's already been defined? Knowing when you have read enough data: you start reading what you have thus far. The length is defined by that, somehow. Is the length given first, followed by the data? Or is there a mark at the end? Or perhaps some of each? To check the checksum, look up the protocol specification for the definition of that checksum. There are many ways to formulate such a value. You have to know how they are doing it, to match that. Broken: depends on what you want to do, and perhaps the protocol definition. It might be designed as being intolerant of errors, such as the medical imaging protocols I've worked with. The specification defines what to do in such cases, going into an error state. Or, it might be like recieiving digital TV over the air, where it must be able to resync after an error so you get some static but then continue. The design of the data protocol facilitates this. So, what is the situation, and what are your requirements?	[reply]