Lobby server design stage

[AF]

I'm at the protocol design stage of my lobby server project. I have quite a bit of free time now (3 months to be exact), during which my time will mostly be split betwen this, AFLobby and helping timblodjik. I estimate if I really pushed ahead, I could have a lobby server up and running as a TASServer replacement within 2-3 weeks.

So before I go anywhere really maningful with the protocol, I'm going to ask for requests and guidance as to protocol design.

My constraints are at the moment:

v1 of the protocol will be plaintext strings like TASServer
multiple protocols can be supported
site integration is on the todo list

Ontop of that generics are a big must, I'd like to think of the protocol more as a transport layer with the client and end module providing the context.

As usual I have a few ideas of my own but Ive not designed a network protocol before so Ill ask first.

One of the issues I can think of is howto handle protocol detection thats backwards compatible with TASServer without imposing restrictions on new protocols.

Note to users, I intend this as a technical discussion, not a feature request thread, you wont get anything helpful here asking for an extra 5 ranks or integrated ladder.

[MelTraX]

So what do you think about using IRC as the protocol and adding some special commands as discussed in the Command Engine forum?

I don't know much about this stuff.. I just think it sounds like a good idea because you/we could concentrate the work on a higher level..

[Michilus_nimbus]

So what do you think about using IRC as the protocol and adding some special commands as discussed in the Command Engine forum?

I don't know much about this stuff.. I just think it sounds like a good idea because you/we could concentrate the work on a higher level..

I don't really see the benefit of extending IRC. Afaik, the only useful feature we could use is the chat. DCC might be useful for file transfers etc, but that's got little to do with the server protocol itself. A simple chat system like we have now isn't hard to implement anyway.

I'd keep the current protocol syntax, except that I'd URL-encode the sentences instead of seperating them with tabs, allowing a more flexible way of parsing the traffic. I think (not sure about this), that this way you don't have to worry about encodings server-side either.

[MelTraX]

Well, I don't really care..

But I don't think it's just the chat.. Each battle room could be a special channel with the settings in the topic and the list command would bring the battle list and other channels.. PMs are also implemented.. I don't know about delayed PMs..

Anyway, just think about it.. Maybe read the linked thread.. But as long as it works I really don't care much..

[Tobi]

Protocol wise IRC doesn't really have much advantages I think, but you get hundreds of chat clients for each and every platform ever made for free, giving people much more choice for simply chatting/idling.

I think you could quite easily make an extended IRC protocol that is only enabled if the client sends a special command. This way real lobby clients can have commands like now (ie. the OPENBATTLE CLOSEBATTLE stuff), and IRC clients can still be used to chat in the server without noticing weird channels etc.

[AF]

I'm not keen on using an IRC server as a foundation, and implementing the basics of the IRC protocol at a later date as another protocol supported shouldnt be too hard.

As a sidenote, I already ahve all the code required for connections, it just has no protocol or any meaningful features in the context of a lobby server, no logins etc, just a plain empty server.