On Tue, Jul 31, 2001 at 08:06:12PM +0100, Julian Morrison wrote:
> Rocco Caputo wrote:
> >
> > On Wed, Jul 25, 2001 at 01:42:52AM +0100, Julian Morrison wrote:
> > > Here is a new module for use with POE
> > > package POE::Filter::SyncStream;
> >
> > [... module ...]
> >
> > > =head1 DESCRIPTION
> > >
> > > A SyncStream is a series of SyncBlocks, each of which consists of a
> > > length in uppercase hexadecimal, a colon, a block of data as long as
> > > specified in the length, and a zero byte.
> >
> > Why do SyncStreams exist, and what commonly uses them? I tried google
> > searches for "syncstream" and "syncblock", but they didn't return
> > anything that looked useful. Do SyncStreams have a more common name?
>
> Invented by me. Name made by me. (Hence the lack of google mentions.)
> The use is for situations where two hosts are communicating over a
> persistent link (eg: in some of my own stuff I'm making) where you want
> the link to stay up even if the occaisional packet gets trashed. If a
> message is garbled to the extent that it gives a wrong length etc, the
> system will try to read it, fail, slurp data up to the next
> synchronzation byte, and pick up the stream again.
Filter::Block does most of this already. It implements
variable-length blocks with the length prepended, but it doesn't
resynchronize if a block's length has become corrupt. I hadn't
bothered with it because I was assuming some reliable protocol like
TCP at the time.
It makes sense to add synchronization and error detection for sending
data across bare serial lines, but I'm more inclined to fix up
Filter::Block than to add another filter that duplicates a lot of its
work.
You're free to distribute SyncStream as a separate module, though. I
can assist in making a distribution out of it and acquiring a CPAN ID
if you don't already have one.
More exciting, and possibly warranting a separate filter (although it
could just be another option in Filter::Block), would be something
that uses the proper ASCII control characters to define records and
transmissions. Here are some of the control characters and their
meanings:
SOH = start of header (a record's metadata)
STX = start of text (a record's payload)
ETX = end of text
DLE = data link escape (to escape control characters)
So "SOH (checksum) STX (data) ETX" might define a block.
Later on you can add flow control:
DC1 = xon (^Q; resume transmitting)
DC3 = xoff (^S; pause transmitting)
There's also:
CAN = cancel (^X; stop transmission)
And there are codes which implement a basic error recovery protocol.
They could accompany a checksum in the record header when you want
more reliability over your error-prone connection.
SYN = synchronization marker
ENQ = enquire (request to start transmitting)
ACK = positive acknowledgment (block is good)
NAK = negative acknowledgment (block has errors)
What's even more interesting is that several devices still use this
old protocol. Credit card terminals do, and it's at the heart of the
protocol for sending text messages to pagers and cell phones.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
