Asyncronous/synchronoug communication: how do the poker clients work?

[YoureToast]

Does anybody know the answer to this question? Are poker sites using sockets? Web services? UDI? Asynchronous/synchronous commuincation?

I'm working on a project that requires similar types of commnication, just not as frequent and realtime and was wondering if anybody had any insight.

Also, anyone know why some sites would be blocked by my firewall and others wouldn't.

Thanks in advance.

[Noodles.]

Obviously they just use secured (Winsock-)sockets...

[matt42s]

Have you been drinking dude?
The typo's aren't your style and UDI - wtf?

Generally speaking - a poker client uses synchronous communication over SSL encrypted TCP sockets. If you thought about it I'm sure you would know that realtime implies synchronous.
I dunno what your firewall is, how its configured or what sites you're referring to but a reasonable guess at the answer would be that some sites use the 'standard' tcp ssl port 443 and (while I dont personally know of any) its quite reasonable to assume that some sites don't - and your firewall may very well reject outbound connections on 'non standard' ports.

[YoureToast]

[ QUOTE ]
Have you been drinking dude?
The typo's aren't your style and UDI - wtf?

Generally speaking - a poker client uses synchronous communication over SSL encrypted TCP sockets. If you thought about it I'm sure you would know that realtime implies synchronous.
I dunno what your firewall is, how its configured or what sites you're referring to but a reasonable guess at the answer would be that some sites use the 'standard' tcp ssl port 443 and (while I dont personally know of any) its quite reasonable to assume that some sites don't - and your firewall may very well reject outbound connections on 'non standard' ports.

[/ QUOTE ]

I am not a professional developer, so forgive my ignornance on this stuff. But I'm dangerous [img]/images/graemlins/smile.gif[/img]. As for the typos, just sloppy -- what can I say?

You're right, I've thought about it. I was thinking that since poker is a turn based game, theoretically it could be done asyncronously, but the problem would be that the server would need to have a means of sending messages back to clients that didn't request a response. OK...got it -- I think! [img]/images/graemlins/smile.gif[/img] Does that statement make sense? If it does, it would help me to know that. If it doesn't make sense, it would help me more to know why it doesn't make sense.

[jukofyork]

[ QUOTE ]
[ QUOTE ]
Have you been drinking dude?
The typo's aren't your style and UDI - wtf?

Generally speaking - a poker client uses synchronous communication over SSL encrypted TCP sockets. If you thought about it I'm sure you would know that realtime implies synchronous.
I dunno what your firewall is, how its configured or what sites you're referring to but a reasonable guess at the answer would be that some sites use the 'standard' tcp ssl port 443 and (while I dont personally know of any) its quite reasonable to assume that some sites don't - and your firewall may very well reject outbound connections on 'non standard' ports.

[/ QUOTE ]

I am not a professional developer, so forgive my ignornance on this stuff. But I'm dangerous [img]/images/graemlins/smile.gif[/img]. As for the typos, just sloppy -- what can I say?

You're right, I've thought about it. I was thinking that since poker is a turn based game, theoretically it could be done asyncronously, but the problem would be that the server would need to have a means of sending messages back to clients that didn't request a response. OK...got it -- I think! [img]/images/graemlins/smile.gif[/img] Does that statement make sense? If it does, it would help me to know that. If it doesn't make sense, it would help me more to know why it doesn't make sense.

[/ QUOTE ]
Pacific uses unencrypted plain text packets. Party sometimes uses the SSL port, but other times it seems to use another port (you can see this by using the netstat command).

As for asynchronous/synchronous then I'm pretty sure you would classify the methods that the poker sites use to communicate as "asynchronous"? Other than stuff which uses UDP (streaming video, VOIP, online games, etc) then most net stuff is asynchronous, but I guess it depends on what "layer" you look at it from (perhaps viewed from the application layer then it might be seen differently?).

From the packet formats I've looked into then the way they work is to make use of the TCP sequence number and store each of the packets in a queue based on the sequence numbers. You can then use the number and the packet's size to predict what you expect the next sequence number to be and make sure you never take a packet from the queue until you see that it has the correct sequence number. For example:

Server sends: Packet 1, Packet 2, Packet 3, Packet 4 (in order).

Client: receives Packet 2, WAITS, receives Packet 1, utilizes Packet 1 then Packet 2, revives Packet 3, utilizes Packet 3, receives Packet 4, utilizes Packet 4.

I think they also must use some kind of time-stamp on the packets and if a certain number of seconds go by without getting the packets they expect the client asks the server to resent it.

Hope this makes sense - Juk [img]/images/graemlins/smile.gif[/img]

[YoureToast]

Thanks Juk.

I think I understand it, but the interesting thing is that now I've received 2 different answers from 2 posters I perceive as both being highly qualified. Hmmmm???

I'm just learning this stuff, but find it fascinating (especially for what I'm trying to do). I don't want to go into details right now, but basically I am working on a project that will have many unique clients communicating with a server. The difference with the poker clients is that most of the communication will be directly between the server and the client and there won't be much communication that needs to go from client to server and then to other clients. To the extent that the latter is necessary, the other clients can make requests for updated information from the server using a timer (every 10 seconds or so). As a result of this, we've decided to use an XML web services model (which is SOOOOOO easy), rather than using TCP sockets. The primary purpose of this thread is to make sure we're not wasting a bunch of time going down this webservice path (I realize I can't know this for sure without revealing the entire project, but the confidentiality of it is pretty important. Although I may find it necessary to reveal it to one of you guys cuz I trust you and consider you as experts...Thats enuf of that rant).

[advis0r]

[ QUOTE ]
From the packet formats I've looked into then the way they work is to make use of the TCP sequence number and store each of the packets in a queue based on the sequence numbers. You can then use the number and the packet's size to predict what you expect the next sequence number to be and make sure you never take a packet from the queue until you see that it has the correct sequence number. For example:

Server sends: Packet 1, Packet 2, Packet 3, Packet 4 (in order).

Client: receives Packet 2, WAITS, receives Packet 1, utilizes Packet 1 then Packet 2, revives Packet 3, utilizes Packet 3, receives Packet 4, utilizes Packet 4.

I think they also must use some kind of time-stamp on the packets and if a certain number of seconds go by without getting the packets they expect the client asks the server to resent it.

[/ QUOTE ]

thats what TCP already does for you :P

applications using tcp dont have to know anything about sequence numbers and lost packets:
"Unlike the UDP protocol this protocol guarantees reliable and in-order delivery of data from sender to receiver."

http://en.wikipedia.org/wiki/Transmi...ntrol_Protocol

[jukofyork]

[ QUOTE ]
[ QUOTE ]
From the packet formats I've looked into then the way they work is to make use of the TCP sequence number and store each of the packets in a queue based on the sequence numbers. You can then use the number and the packet's size to predict what you expect the next sequence number to be and make sure you never take a packet from the queue until you see that it has the correct sequence number. For example:

Server sends: Packet 1, Packet 2, Packet 3, Packet 4 (in order).

Client: receives Packet 2, WAITS, receives Packet 1, utilizes Packet 1 then Packet 2, revives Packet 3, utilizes Packet 3, receives Packet 4, utilizes Packet 4.

I think they also must use some kind of time-stamp on the packets and if a certain number of seconds go by without getting the packets they expect the client asks the server to resent it.

[/ QUOTE ]

thats what TCP already does for you :P

applications using tcp dont have to know anything about sequence numbers and lost packets:
"Unlike the UDP protocol this protocol guarantees reliable and in-order delivery of data from sender to receiver."

http://en.wikipedia.org/wiki/Transmi...ntrol_Protocol

[/ QUOTE ]
Yep, thinking back I was manually capturing the packets using WinPCAP and prolly could have found some better way that didn't involve all queueing work (perhaps WinPCAP even has some other buffered mode, but not sure).

Juk [img]/images/graemlins/smile.gif[/img]

[advis0r]

ah, now i see what you were talking about. you were sniffing the packets and had to rebuild the tcp datastream. sry for trying to be some sort of smartass ;P
dunno if winpcap does have something for this, but capturing a tcp stream (in order) should be a pretty common problem so i guess a solution might be already out somewhere [img]/images/graemlins/smile.gif[/img]

[jukofyork]

[ QUOTE ]
ah, now i see what you were talking about. you were sniffing the packets and had to rebuild the tcp datastream. sry for trying to be some sort of smartass ;P
dunno if winpcap does have something for this, but capturing a tcp stream (in order) should be a pretty common problem so i guess a solution might be already out somewhere [img]/images/graemlins/smile.gif[/img]

[/ QUOTE ]
It wasn't that bad to make the queue, but I do seem to remember reading something about the sequence number should not necessary be sequential (perhaps hashed [for security reasons?]), so it might not always be that easy to do yourself.

Juk [img]/images/graemlins/smile.gif[/img]