On Thu, 17 Jan 2008, nash wrote:
> > The clients should be able to, without pipelining do the following:
> > connect frame
> > <- reply
> > getFeatures
> > <- reply
> > setFilters
> > <- reply
> > <set filters active>
> > then start pipelining.
>
> Most annoying part of the protocol to be frank ;-)  Hence if there were
> mandatory filters, I'd do something like:
>       connect mesg
>       -> reply
>       getFeatures (protocol requires I believe)

Nope, only the connect message is required.

>       setFilters
>       -> reply features
>               ->record anything
>       -> filters okay
>               [set internal parser replies to use this]

You could do this, but you have to be careful about when you enable the 
filters. The server too will have to be careful (of which tpserver-cpp isn't 
yet) to make sure that synchronised.

> > Although.... you probably don't want to pipeline around login.... (state
> > change).
>
> Depends on how much you hate round trips... ;-)

True, but it will save bandwidth if you wait and the the reply is fail.

> > > >  - client's implementation is known to be incorrect
> > >
> > > Personally I'd say for the last case:
> > >   - Let the client be incorrect, fix it in the client.  Work arounds for
> > > other bugs suck... this is one area open source can get advantage ;-)
> >
> > What do we do about the client in the mean time?  In particular if it's
> > like tpsai-py and automatically re-establishes the connection after it is
> > drop for a good reason (like lost synchronisation, corrupted packets,
> > etc).
>
> Nothing.
>
> If the amount of time required to fix the client is that drastically
> different, then the change to the server would be to add that client to
> a blacklist.

Except if there is a client from outside our immediate project, or (heaven 
help us) a commercial client with a bug in it. Just look at the various 
provisions in Apache for working around broken HTTP/1.1 implementations 
(early versions of Java springs to mind).

>       Regards,
>       nash

Later
Lee

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel

Reply via email to