   Need a clever way to solve this server-client issue.
  Im working with cell phones.All cell phones use httpconnection as its means of protocal, nothing else is available.the game in question is a poker game.here is a scenario:suppose i have 4 players (A, B, C, and D).say A sends to server information that A has folded its hand.then, ideally, the server should send to all other clients this information so that each client can reflect that on their side (that player A folded, therefore, do whatever graphical feedback to indicate as such).here is the problem:only a client can initiate a connection.so HOW can the next player B know that it is his turn when player A folds?  Unless i go strictly by timed-turns, and somehow hiding the fact that each player is timed (no matter what the player does)....i cant figure out a way to do this.could there be a really clever way to keep the flow of this poker game going with the handicap of the server being unable to initiate a connection?also, the server-client connection, being an httpconnection, can only send one time for the client and one time for the server, per connection.  on top of that each transfer costs money.this is for cell phones by the way.any clever geniuses out there? 
  Have each client ALWAYS keep a request outstanding, that''s blocked in the server. When there is an event for the client, un-block the request on the server side and return the data; have the client then re-connect waiting for the next piece of data.If your client side does not provide asynchronous requests, then you have to un-block every two seconds or so and return "nothing happened", which would suck. (That''s a technical term) ;  the client makes a connection, not necessarily requests one.each connection costs money (air-time plus download-time).;  Yes, what I suggested includes the client making the connection.Yes, I know connections cost money. That''s the price you pay for playing poker online.;  there is no gambling involved with what im talking about.everything i mentioned is independent of the game itself.air-time and downloads (per KB) costs money for mobile games/applications. ;  So let me clerify this, Only clients can make connections and each connection serves the purpose of sending and recieving one update. After the update the connection is severed to save airtime. The server cannot initiate a connection with a client.This setup seems to put a real fork in a client server setup. In order to ever keep the clients updated they would have to connect periodically to the server to check for updates. Im not exactly sure the capabilities of cell phones but it seems to me that if its possible for the clients to communicate to eachother it would be easier to save airtime. The following scenario would be the most efficient if possible.Client A folds connects to B and sends a message to client BClient B recieves the fold message and sends to Client CClient C recieves the fold message and sends to Client DorClient A folds and sends a message to each ClientA client-server setup with clients always connected seems the most viable way to solve this problem. Air time and data transfer must be expected when playing multiplayer cell phone game. ;  thanks for your input.but your idea of my client-server restrictions is correct.- only client can initiate a connection.- client must send first (once per connection).- server has one chance to send something to client, but only after receiving something from the client.- you cannot, unfortunately, send from one client to another.i think i am going to have to stick with the timed method where at every so-many-seconds each client sends an update request message to the server, upon which time the server will reply.each kb sent costs money. so does the general air-time.this might be the best way around this limitation. ;  Did you actually understand the suggestion for how to have a request outstanding to the server, and only un-block that request on server side when the server wants to send a message to the client? 