UGS Protocols

    Keywords: Online Go

Table of contents

Go game/server Related Protocol

Whether or not we're using a hierarchical server or a single server (especially for the first round of design) certain elements are required for the Go game. At first, a listing of these elements would be most helpful - these will change into actual requirements as they are agreed upon.

The form of these messages should be decided before structural (low-level) requirements are written. Example: <MESSAGE TYPE>=<DATA FIELD 1>,<DATA 2>,...<DATA N>

Jabber and hierarchies, groups, rooms etc

[ext] Mikea's Draft mentions two Jabber Extensions that could be used for multi user rooms and room hierarchies: [ext] JEP-0045 and [ext] JEP-0030, I think this needs discussing more to see exactly how these will fit in with our vision, and what modifications or extensions may be required.

The multi user chat protocol - JEP 0045, handles affiliations, which are lasting associations to a roam, plus roles which are temporary for just the one visit. The different roles are:

  • Moderator
  • Participant - permision to speak
  • Visitor - not allowed to speak
  • None - not present in the room

The associations:

  • Owner
  • Admin
  • Member -becomes a participant in moderated rooms, can enter member only rooms
  • Outcast - banned
  • None

I feel we should make full use of these features for UGS, but JEP-0045 does not deal with relationships between rooms, and is designed with mainly chatting in mind. Should these associations be expanded to deal with other roles and permisions, such as downloading files, being a player in a game rather than a bitzer etc?

Associations to rooms also need to also be valid for subrooms, so If you're a member of "English go room" then any games played in this room you are also automatically a member of. Any service can be a subservice of any other subservice, with all permissions carried over, but with the option to override these permissions.

Mikea: Most JEPs only specify the interfaces and the business rules related to them. The way you organise the internal business rules for defining how the service behaves is up to you. If you were to use my example model, then the Auth service can supply this information by various means to be determined by the project.

20050218 Mikea: A groups component was released today. This is Jep-0144 Shared Roster Groups, which could be implemented/reused. It can be found here [ext] http://www.cd.chalmers.se/projekten/jabber/clubs.html

Regarding ports

Malweth: After running a search of jabber.org, I found [ext] this e-mail about connecting over port 80 (and its difficulties).

It still remains that, to enable IP traffic wrapped into XML/html over port 80, we will require multiple servers (or some sort of port sharing between components). It seems likely that we'll require a fair amount of customization to any protocol we adapt. Additionally, functionality when using a port 80 "html feature" will needfully be downgraded.

Personally, (because of firewalls) I'd like to see three levels of service:

  1. Regular service over a standard port (8000, etc)
  2. Direct-connect service over the telnet port (23 I think) - many firewalls still allow telnet
  3. Downgraded service over WWW port (80)

In terms of the protocol/code, allowing three ports simultaneously with three classes of service will either mean the customization of a 3rd party stack, the creation of our own protocol and stack, or having subservers that allow such things.

Benjamin: Maybe like with the architecture, I'd propose to keep multiple levels of service in mind while just implementing one for the prototype. But about Jabber: I still can't judge where exactly (and how much) jabber could help us. I mean, as we'll have to define our xml-protocol ourselves anyways, we can't expect much more than having it do xml-streaming and data transfer for us right? But this doesn't seem so much work for me anyways - or am I missing any point?

Edrin: Afaik it is not a problem to use Jabber over http proxy anymore. The best example is JWChat - [ext] http://jwchat.sourceforge.net/ This client is a mix of html+javascript only and runs in a webbrowser. The advantages Jabber brings: 1. There are many free opensource protocol libraries available for all important languages. 2. It IS the well defined Internet standard for communication. 3. It could happen that some of the active Jabber Client developers might add your specifications/your game to their clients. 4. As you can see there is much support from the Jabber Software Foundation ;)

Benjamin: OK, let's start with Jabber. Anyways, if we encapsulate communication well, it would be very easy to switch to sth. else later if we get problems with it later (thinking of speed or whatever might occur). Btw, how can we make it possible to have a pure web-client for UGS that uses (at most) sth. like javascript? It'd be really neat if everybody could play from everywhere without even having to install javascript - e.g. I would like to play from a library at university...

Malweth: Sounds good to me! I'd also like to see UGS connect into the Jabber network at some point - simply broadens the connectivity to the Instant Messaging world...

A web client definitely has innate problems - if Java is unavailable, it becomes more like Dragon Go Server or LittleGolem. Although a PBM type server/client is certainly possible (and I believe it's on the wish-list), a real-time web based client may require fast refresh rates - blitz might well be impossible.

One possibility would be to have a seperate window or frame that performs all data transfer and updates the main window/frame with any new information. I'm not sure how well this would work, but it seems as though Jabber would be an ok protocol for this...

In any case, I'd suggest waiting until there were sub-servers to delegate this task to (e.g. well after the first phase of coding) as it seems like a very large and not-core feature. This would also allow this subserver to be dedicated to this task while the main server (or another subserver) can handle other web based tasks.

Benjamin: Ok, fitting to our policy: Keep in mind we might want to implement it later, but not for the prototype :-)

Malweth: I'll try to put together a set of (high level) reqs for phase one by next week or so and we can open it for comment... We'll keep Phase 1 based on core needs only and try to keep it modular. P2 is when we can look deeper into the features. Sound good?

Benjamin: Jeah, great!

[ext] Speex (Codec)

Description

The [ext] Speex codec provides for much smaller file sizes than MP3 codecs. [ext] Speex is limited to speech only. It is open source and non-patent (free use).

Discussion

This would likely be the best method for transmit and storage of games / lessons with audio. Some modification (to game records or codec) might be required to align the audio and SGF.

Benjamin: Sounds very nice!


mdm: I added some lengthy criticism on the protocol choice and network-model here.


This is a copy of the living page "UGS Protocols" at Sensei's Library.
(OC) 2011 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About