On Fri, 2009-07-10 at 10:44 +0200, Loic Dachary wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > At the moment a poker-network REST server imposes a constraint to the > client : when a user is logged in it can only open a single session. > It makes sense for when a user plays at a poker table. When the user > polls the server, the packets that describe the actions done since the > last poll must be sent. > > What we would like is to be able to open as many sessions as the user > wants. The only problem I see at the moment is that for a poker table > there can only be one session for the user to play. There can be > multiple observers, but the logged in user cannot have two sessions > acting on behalf of the same user on a table. That could be the case, > for instance, if a jpoker session co-exists with a pok.me session. Or > if two tabs on the same navigator are open on the same table. > > At the moment the latest session wins and all other sessions are > terminated. It is maybe enough, for a first step, to limit this > restriction to a player sit at the table. It is better explained with > an example, I'm not being very clear ;-) > > At present: > > Tab One : TableSelect ( countfilter = 1 ) : ok > Tab Two : TableJoin ( countfilter = 2 ) : ok > Tab One : TableSelect ( countfilter = 1 ) => disconnected by the > countfilter restriction server side > Tab Two : Seat ( countfilter = 2) : ok > > The above is useless but if the two tabs do TableJoin, only one will > get the packets describing the table action instead of each tab > competing to get half of the packets and crash. > > What we want: > > Tab One : TableSelect : ok > Tab Two : TableJoin : ok > Tab One : TableSelect : ok > Tab Two : Seat : ok > > And (probably but not sure): > > Tab One : TableJoin game 400 : ok > Tab Two : TableJoin game 400 : ok > Tab One : Seat : ok ( count acting at game 400 : 1 ) > Tab Two : Seat : ok ( count acting at game 400 : 2 ) > Tab One : Poll for action : count acting at game 400 == but current is > 2 : the session becomes an observer session instead of an acting session > Tab Two : Poll for action : ok ( count acting at game 400 : 2 ) > > The general idea is probably that we keep the limitation of a single > acting session for a given game. But not for all other actions. And > instead of just crashing the client, the acting session becomes a > viewer session. > > Comments are welcome. This is a delicate part of the server code and > our goal is probably to minimize the changes and, if possible, find a > simple solution. >
Hi, Keep in mind that it would also require some client side works in order to notify the player that a table display is viewer only, and that it can't interact with it. Maybe we can make overridden connection behave like anonymous ones: Tab One : Login Tab Two : Login Tab One : Poll -> Logout -> Observer But that would require to change the way poker-network handles connection cookies. An alternative solution would be to have a rest filter that keeps a separate queue of packets per connection id (identified by the connection_count cookie). This way simultaneous client would be able to refresh and interact with a table. We should also not forget that all packets are not table related: /me thinks of outbound PokerTable due to tournament start, and ping/pong packets for tourney registrations, etc. -- Johan Euphrosine <[email protected]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pokersource-users mailing list [email protected] https://mail.gna.org/listinfo/pokersource-users
