> > Probably bad terminology. I thought there were going to be filters that
> > all servers must implement:
> > - String padding
> > - Compression maybe[?]
>
> I was not under that impression. I thought that all filters would be optional
> to implement.
mithro?
> > [/me notes that yes it does, and it's annoying in a client which
> > pipelines _everything_]
>
> I would hope that you don't pipeline around the initial connection, ie, check
> that the other end is indeed a TP server.
[off topic really ;-)]
Depends on exactly what. I will parallellise as soon as the login
request is sent, after all if it fails, the rest will too, so no loss.
However the real message storm starts when the 'login okay' event is
triggered internally (which also triggers a start turn I do believe).
Essentially I don't like anything to wait ;-)
> 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)
setFilters
-> reply features
->record anything
-> filters okay
[set internal parser replies to use this]
> Although.... you probably don't want to pipeline around login.... (state
> change).
Depends on how much you hate round trips... ;-)
> > > - 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.
Speaking of which...
Regards,
nash
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
