Re: Suggestions for custom application-layer protocol?

• Previous message: Walter Roberson: "Re: Suggestions for custom application-layer protocol?"
• In reply to: David Schwartz: "Re: Suggestions for custom application-layer protocol?"
• Next in thread: David Schwartz: "Re: Suggestions for custom application-layer protocol?"
• Reply: David Schwartz: "Re: Suggestions for custom application-layer protocol?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

• Previous message: Walter Roberson: "Re: Suggestions for custom application-layer protocol?"
• In reply to: David Schwartz: "Re: Suggestions for custom application-layer protocol?"
• Next in thread: David Schwartz: "Re: Suggestions for custom application-layer protocol?"
• Reply: David Schwartz: "Re: Suggestions for custom application-layer protocol?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]