[Standards-JIG] proto-JEP: Game Sessions

Tue Sep 19 15:07:07 CDT 2006

On Tuesday 19 September 2006 10:58, Michal vorner Vaner wrote:
> On Sun, Sep 17, 2006 at 10:45:29AM +0300, Mircea Bardac wrote:
> > On Tuesday 12 September 2006 20:25, JEP Editor wrote:
> > > Abstract: This document defines how to initiate a game session over the
> > > XMPP protocol
> >
> > Apparently, the JEP does not only define how to initiate a game session,
> > but also how to send messages between the peers. This looks like a minor
> > conflict between what it actually does and what it says it does.
>
> No, it does not. It only does the initiation.

My comment wanted to point out that you also want to describe delivery (as 
in "message forwarding"), something which is not part of the *initiation* - 
thus the contradiction between the Abstract and the content.

> > > URL: http://www.jabber.org/jeps/inbox/gamesessions.html
> >
> > The whole idea of forwarding messages from one peer to another looks like
> > a misuse of Jabber for me. IMO, all game types can easily be mapped over
> > a MUC component.
>
> Hm, that is another idea. However, the problem with MUC is, it does NOT
> send everything, but only messages bodies. Which is misuse of muc
> component for me, if the data were sent trough messages if <iq> would be
> needed.

Hmm.. this is XML. You can wrap anything in XML, as long as it doesn't 
conflict with something in the currently-in-use namespace.

Therefore, 

<message type="groupchat" to="someroom at conference.someserver.org" id="abc" >
  <iq xmlns="http://jabber.org/protocol/gamesession">
    <session-started />
  </iq>
  <body>Session started.</body>
  <nick xmlns="http://jabber.org/protocol/nick">IceRAM</nick>
</message>

is perfectly legal and gets to be forwarded completely. I've named the 
in-message-tag "iq" just because you wanted to send IQs (I've tested the 
above stanza on conference.jabber.ru and it worked, being sent completely). 
I've added <body>...</body> just to make it show with a regular MUC client - 
works well without it either.

The main difference between messages and iqs from the protocol design point of 
view is that messages don't require confirmation and iqs do require 
confirmation (<iq type="result" id=abc" /> ).

The confirmation can be easily overcome by the fact that, once the MUC 
component received the message-stanza, it forwards it to all MUC 
participants, INCLUDING the sender. Once th sender receives the sent message 
(same id), you can consider that the confirmation arrived. It is no longer 
your problem as a client (sender) to THINK of the transport - the transport 
layer delivered/tried to deliver the message to all participants.

> I actually wanted to have something like game server component, which
> could act as the said server - creating sessions and resending data.
> Maybe I will need to define it somehow, but I thought it would be in
> another JEP.
>
> I do not like the idea of mapping data over MUC - multi-user _chat_.
>
> And it is quite an overkill, if I had to negotiate with a MUC first,
> then send it to the other and so on. For example chess game, it seems
> easier this way for me.

I probably didn't make myself clear. MUC would only be used as a transport 
layer. As a side effect, it would also keep (as roles) the statuses of the 
game session users. You can also kick/invite in a room (which would be a 
synonym for a "session").

Think of the following: in any other implementation, this protocol would have 
to:
1) first establish a connection with the transport layer [open a TCP socket]
2) After the connection is established, the transport layer gets connected to 
the other peers (invite/join) [TCP connect/accept]
3) Once the peers connect, you need to start a session (this is another 
layer). [start own protocol over the connection]

MUC maps perfectly for the transport layer, before session is started.

> > There's a JEP in inbox/ named: Shared XML Document Editing
> >  http://www.jabber.org/jeps/inbox/sxde.html
> >
> > I remembered it because it describes how one2one/multi-user sessions are
> > started. Theoretically, anything can be mapped over these sessions,
> > including gaming AND whiteboarding (with saving, sync-ing, spectators
> > etc.)
>
> Game can be described by changing document, yes, but it may be described
> by flow of events as well, which does not need to be remembered. Which
> means, shared document is not good for these games.

First of all, that document is still draft.
Second of all, it was only thought for documents, not games.
Third of all, the document does not mention that replaying the history is a 
must.

Above all, that document tries to describe a session, just like the 
gamesession JEP tries. The session would be used in different modes, but 
still.. it would be a session for multiple users.

> Hm, if you find out how to persuade MUC to send iq messages, than
> probably yes.
See above. It works. It worked for me.

> More, with MUC you see who you are playing with, there may 
> be games where you don't know who do you play with/against or how many
> of them are. (well, I do not have any specific game in mind now, but MUC
> would make it impossible). Or is there a way how to solve this?

When I said to use MUC as a transport layer, I didn't mean "show the IRC-style 
dialog for the users". In any implementation, it is at developer's desire to 
show or not to show the participants in the game, given that, AT SOME POINT, 
the playerlist is sent in the session.

If you need extra options you can either:
1. develop a new server component for a transport, possibly forking a MUC 
component.
2. extend MUC with a "totally anonymous" option or something, to be activated 
on room creation

2nd of all, the true JIDs of the users in a MUC room are only seen by 
moderators. When a user sends a message to the room, the message appears to 
be sent from his cloaked identity.

Regards,
Mircea

-- 
http://mircea.bardac.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20060919/15a7577b/attachment.pgp