[Standards-JIG] proto-JEP: Game Sessions
dev.list at mircea.bardac.net
Tue Sep 19 20:07:07 UTC 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
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.
<message type="groupchat" to="someroom at conference.someserver.org" id="abc" >
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
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards