Documenting protocols

[metlslime]

I took a shot at documenting the fitzquake protocol here:

My approach was start with the nontechnical feature list at the top, useful for mappers/players/quakec peeps, then have section explaining the specific changes for engine coders, then finish with raw #define type stuff (also for engine coders.)

Any thoughts?

[mh]

Nice idea.

I've wanted to add the FQ protocol to my engine for a while, maybe as the default, and now it's just so much easier than hacking around with the BJP protocols was.

The only thing I see lacking is that you don't seem to extend the positioning, so it's still quantized into shorts. It's not that big a deal (how many maps actually use positions beyond +/- 4096 in all directions? how many map editors support them?) but it would have been nice to see a U_LARGEPOSITION also.

One other thing I haven't yet checked in your code is whether or not you've increased the message buffer size, which will probably be needed at some point.

[Spike]

one thing I would personally be interested in is if there is some way to detect if a client supports this stuff, rather than instantly crashing it if it does not, even if none of the extra bits is useful.

Also, U_LARGEPOSITION on its own is not enough. It needs to potentially apply to all coords.

[mh]

Ideally when the client receives it's PROTOCOL_VERSION from the server there would be a mechanism where it could say "nope, don't know about that one, here's a list of the protocols I do know" and the two of them could then work out something in common (with the option for the server to be able to specify certain things as mandatory, so as to ensure that all clients are on an equal footing so far as critical gameplay matters are concerned). Seems better than the current Host_Error, but it would need to be retrofitted to even current protocol 15 implementations and you just know that everyone's gonna do it differently.

[metlslime]

[mh]

[Spike]

[metlslime]

[metlslime]

[Spike]

if it is the interval/duration, then lerpfinish is a misnomer. :P
Which, yes, would only be sent when properly required.

Regarding connection stuff, the client asks for a connection, and the server sends an ack packet and instantly starts sending 20+ packets every second from a single potentially-spoofed packet... Which is my most major gripe about NQ protocols.
The problem is that with that you can spoof ip addresses and then fully clog up a server with X dead clients that the server is constantly sending packets to. So either a denial of service attack on the server, or use a few servers and you have a denial of service for someone else. Because the CCREQ_CONNECT packet can be spoofed, its not possible to ban the DoSer.
QW+Q2+DP onwards use 'challenges', where the client has to respond with a magic cookie before any client slots are actually consumed, so you know they actually have control of that ip before you start spamming it. Also, by having the client acknowledge a challenge, you can easily route through client-side NATs (so long as the client sends the reply to the server's new port).
But now I'm babbling.

I had a quick peek at the server source, and it looks like it would be just fine with extra data tacked on the end. From memory, proquake does just that to carry the extra info to get it through NATs. From memory, proquake include a magic code to avoid bad things from happening if others add stuff too, but I've not checked that.

[mh]

To my mind, the ideal protocol is one that's designed from the outset to be extensible. The basic version would be almost identical to protocol 15, but after sending the protocol version the server would send a number of flags.

First is "mandatory flags", a single int specifying which extra features are required (a server admin could be given the ability to toggle these via cvar), with a MOREFLAGS optional bit specifying another int of mandatory flags to follow (which can also have it's own MOREFLAGS bit, and so on). A client that doesn't meet these requirements is going down in smoke, either with a Host_Error immediately, or with an "illegible server message" at some point during gameplay, as the server will always send messages based on these.

Second comes "optional flags", which clients can choose not to support if they wish. The same MOREFLAGS pattern applies. The client reports back to the server which of these is supported (as part of the signon reply), and we're off. The server can filter out which of these items it will send messages based on, depending on the report back.

This would allow a single standard protocol to evolve without breaking compatibility, and would put control of protocol features in the hands of server admins (it would also enable mod-breaking features to be toggled as required). The downside is that every engine would likely end up with a partial implemenation, but at least things would have been designed to mitigate that.

[mh]

Anyway, all that aside, I think we can now say that there's another engine that implements protocol 666 - or at least it will in it's next release.

[metlslime]

[Baker]

[mh]