On Fri, 18 Jan 2008, Brett Nash wrote: > On Thu, 2008-01-17 at 19:33 +1030, Tim Ansell wrote: > > On Wed, 2008-01-16 at 23:28 +1100, nash wrote: > > > > > 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. > > > > > > Saved a message then ;-) > > > > Actually I think you should be able to send these frames as the first > > ones, > > - get features > > - get games > > > > We could easily add the server identification string to both of those > > frames (and it actually makes sense too). > > > > Lee, why did we ever want a connect frame anyway? It's pretty easy to > > tell if you have a valid TP frame quickly. > > Isn't it for the redirect frame? Or the Sod off, use SSL on port ++?
That is part of it. The main reason for the connect frame is to have a frame that is really only there for checking the version number and the client-id string. Yes, it would also be good to do redirects at this point. The initial version check is expensive, checking for HTTP headers, that TP and then the correct type of version number is present, and in future check for SSL. I believe that tpserver-cpp does actually handle getFeature frames as well as connect, but I could be wrong. On the client side, it's a handy way to check that the other end is indeed a TP server, version numbers match up, etc. before jumping into requests. > Regards, > nash I can see some benefit to discuss this starting state (ie, up to login) to make sure it works ok and keeps everything possible. Later Lee
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
