Re: Suggestions for custom application-layer protocol?

From: Walter Roberson (roberson_at_ibd.nrc-cnrc.gc.ca)
Date: 05/26/05 

Date: 25 May 2005 22:40:48 GMT

In article <d72lu4$pn$1@nntp.webmaster.com>,
David Schwartz <davids@webmaster.com> wrote:
: You can take a page from the URL encoding scheme and use a list of
:<param_name>=<value> pairs delimited by [...]

: Specify that each end ignore any parameters they don't understand
:(rather than considering it an error), and your protocol is extensible.

I disagree. If you ignore parameters you don't understand,
then you may well be ignorning something that changes the meaning
of something else that you thought you understood.

When I last did this kind of protocol definition work, the first
thing I had the two sides exchange is their respective protocol
revision numbers. Each side would have a range of versions over
which it was able to support backwards compatability; if
the two sides were too far apart, then either end could say
"Sorry, I don't know how to talk to you."

You could offer "ignore what you don't understand" extensibility
within a protocol release provided that the extensions don't
change the meaning of any established parameter, and the
extensions don't command anything critical. For example,
if one added an arrow-shape parameter to a graph, then
likely it would be considered acceptable if the other end
ignored the shape parameter -- but a new parameter that
indicated (e.g.) "Turn off motor #7!" is probably too important
to ignore. Any time there is a notable semantic change or
critical command change, the version number should get a boost.

Note to the original poster:

One of the other issues that I ran into, which might or might not
be relevant to you, is that some of my operations could take
a long time. I needed command response timeouts; and I needed
keep-alives so the one end would know the other end was
working instead of hung up; and I needed a way to interrupt
executing commands. [My code was single threaded and
non-preemptive, so I had to put in co-operative multitasking
hooks.] There's no clean equivilent to ^C over a network connection ;-) 

-- 
  The rule of thumb for speed is:
  1. If it doesn't work then speed doesn't matter.  -- Christian Bau

Relevant Pages

  • Re: Suggestions for custom application-layer protocol?
    ... :, and your protocol is extensible. ... extensions don't command anything critical. ... critical command change, the version number should get a boost. ...
    (comp.unix.programmer)
  • Re: Suggestions for custom application-layer protocol?
    ... Specify that each end ignore any parameters they don't understand ... >:, and your protocol is extensible. ... > extensions don't command anything critical. ... > critical command change, the version number should get a boost. ...
    (comp.os.linux.embedded)
  • Re: Suggestions for custom application-layer protocol?
    ... Specify that each end ignore any parameters they don't understand ... >:, and your protocol is extensible. ... > extensions don't command anything critical. ... > critical command change, the version number should get a boost. ...
    (comp.unix.programmer)
  • Re: USBIP protocol
    ... you mean when we rev the protocol to version 2 ... Set Configuration and Set Interface are requests on the command pipe ... according to the usb 2.0 spec (these would be a control message ... request on the command pipe. ...
    (Linux-Kernel)
  • Re: use of small kana on the increase?
    ... USENET should be capitalised, especially if you are talking about the ... protocol, ... tr is a command. ... I'm sure some guides have it as 'translate'. ...
    (sci.lang.japan)
Loading