Hi group,
>
> It's been along time since we started using our CSV-like protocol. Now
with
a new terminal coming up, I think it's time for a recap on this protocol.
I
think the used protocol is not the most flexible/small protocol we can
get.
But I would like to have, because of transport-costs. It has to stay
> readable character-oriented.
>
> It looks a little like this: TST11,22,33,44,,,77. Where TST is the
> identifier and 11 to 77 are parameters send to/from the terminal. Looks
> okay. But the tricky part starts when (1) parameters are left out and a
> bunch of comma's have to be send (TST11,,,,,,77) and (2) when a message,
for
instance this one, has to be extended it will always have to be extended
in
the back-part of the message, with (in both cases 1 and 2) always having
the
drag of the comma's even when these aren't send for years. Removing the
not
used values from the message (to have ,,,,) we called stripping.
>
> Another, more flexible, protocol I was thinking of looks like this:
> 2551399111777
> Where are single karakters , .
After
each there is a parameter-id and after each there is a value.
>
> At this time we use a form of compression where almost all message-id's
like
TST are compressed to single-byte values. Don't know if we need that with
a
good protocol.
Read the Telnet RFCs, to see how they solved this problem WELL OVER TWENTY YEARS AGO.
Read the PPP RFCs, to see how they solved similar problems WELL OVER TEN YEARS AGO.