[cutedge]

Hello,
I am curious about something. Since over the air transmissions can have intermittant packet loss, how does SNAP mobile handle this? Is it built into the SNAP mobile API or does each developer have to implement their own solution?

[mikbry]

Packet loss is managed by TCP protocol. SnapMobile and other Mobile Multiuser servers use this protocol for communicating. Due to Operator restrictions and proxies, UDP isn't possible.
So best is your connection, best is your bandwith and the lag is lower.

Mik

[cutedge]

Yes, a packet is sent through the connection by TCP (or HTTP, which sits on top of TCP anyway) to the SNAP server, which then handles sending it to the other clients. The question is, do the SNAP servers handle making sure the packet gets to the client? I ask this because the packets are not sent to the other client, they are sent to the SNAP server which delivers them by proxy. Does the SNAP server resend a packet in the case that it is lost while "in air" between the carrier provider and the phone, or is that the carrier's responsibility (or worse, the game developer's)?

I know that the SNAP API will tell us if there was a problem getting from the phone to the SNAP server, but I'm curious on how the rest is handled...

[mikbry]

You don't have to take care of packet loss, it is TCP job:
http://en.wikipedia.org/wiki/Transmi...ntrol_Protocol

[cutedge]

Yes, I know that TCP normally handles it. What I'm curious about is what happens when a packet gets lost "in air". I ask this because I am seeing packet loss in testing.

If the SNAP server isn't getting any sort of acknowledgement besides the TCP ack that says that the packet got to the carrier provider, then it would be up to the developer to implement a solution, which seems like a bad idea since it would require sending the first packet from phone to carrier and then from carrier to phone (with the snap server in the middle), and then sending an acknowledgement back from phone to carrier and then from carrier to phone, which would take way too much time.

Feel free to correct me if i'm wrong, but I don't think the underlying TCP connection takes care of this issue.

[mikbry]

The mechanism of TCP is to send all packets in the right order to the client/server. So yes, you have different ACk/SYn/Waiting states like you suppose. It takes more times than a RAW UDP, and more time/bandwidth is taken if connection is bad. The only packet loss is from a server error, a timeout, a client disconnection. But in this case, you need to relogin, as docs say. Like when you browse / retreive emails on your phone, if connection is good you get all your data...
Using other protocols like UDP Socket, or RTP isn't possible mainly due to operator network limitation. A gateway filter out not standard TCP/HTTP/WAP/WSP requests in most case. And ports are locked. So fullbandwidth multiplayer isn't for today...Maybe WIFI connection will change that.

Mik