   TCP vs UDP for Online Poker Game
  Hi Everyone, I am having a bit of a dilemma at the moment whether to use UDP over TCP for my online poker game. My game architecture is something like the following. There is a client application which just contains the UI. No logic happens client side.There then is one master server as well as multiple game servers. A game server can have over a hundred tables running on one machine and there can be multiple game servers running over many different machines. I want this to be extremely scaleable. The game servers alert the master server with simple statistics such as how many players are in a game / when a player leaves etc. All game logic happens on the game servers.A client connects to the master server first where they can see what tables have positions available etc. When they select a table the master server transfers them to the corresponding game server where they then connect to in order to join the table.What transfer layer protocol would be best to use as a foundation to build my game protocol on? I would be inclined to go with TCP but was wondering what if any benefits UDP may offer over it in this situation.Edit:Also is it better to develop my protocol from scratch as an array of bytes with custom headers etc or just use serialized objects or something like remoting in c#RegardsJohn.[Edited by - clearz on September 11, 2007 6:57:15 AM]
  Without any doubt I suggest you use TCP. As for the protocol, developing one from scratch isn't to difficult for a poker game. Serialised objects would also work.RegardselFarto   ;  I second the notion of using TCP.Messages to the server nedd to be sent reliably and in order. You could use UDP and write your own reliability layer but you usually only do that when you might not care about in order processing or theres a tolerance for dropped packets. For example movement updates in an FPS. If a movement packet is dropped the next packet can correct any anomalies that may have occurred as a result of the drop.With an online card game, if a player bets or folds, that information has to get to the server or else the game does not continue (or at least until your turn times out). -=[ Megahertz ]=-   ;  Your type of game has low thruput and low data amounts and high tolerance of lag/secondlong delays, so optimizing data transfer isnt critical.   Reliability is simpler to impliment for your game in TCP (your high level protocol will be  sending events and getting acknowledgements to allow game phases to move forward (or to handle timeouts caused by various reasons).One possible thing that you may face is if you try to put too many TCP sockets on one machine, but I recall that usually that number is in the thousands and some overhead/delays is not a game killer.Im not sure if NAT problems still make trouble for TCP  (in the past that was one issue that UDP was better). Others here could probably answer that aspect in your case.   ;  Thanks guys I was pretty sure about TCP anyway. I am interested in hearing some ideas about the second part of my question. Should I develop a protocol from scratch or just serialize objects across the network. The latter seems to be the easier and quicker way by far but what would be the benefits of writing my own protocol myself.John.   ;Quote:Original post by clearzbut what would be the benefits of writing my own protocol myself.The benefits are those that you give your protocol.Lightweight implementation, low memory overhead, compactness, responsiveness, .... Or... poor implementation, buggy, unreliable, crashes, wastes memory, ....3rd party full object serialization has one problem that has been pointed out here before - it's not tamper proof.Consider that you're expecting client to send you a list or a string. All that attacker needs to do, is send a malformed packet, that indicates your list containes 2^31-1 elements. And your serialization stack will read that, and happily allocate 2 gigs of memory. 50 times. For each of 250 malicious clients.   ;Quote:Original post by clearzI am interested in hearing some ideas about the second part of my question. Should I develop a protocol from scratch or just serialize objects across the network. The latter seems to be the easier and quicker way by far but what would be the benefits of writing my own protocol myself.I would develop the protocol myself, it's worth it just to get the experience.RegardselFarto;  I would love to write a custom protocol even for the experience alone but there seems to be little in the way of documentation out there. I have looked over some of the RFC's  for existing protocols but I would like to read a few tutorials on the topic. Does anyone know or can anyone point me in the way of such tutorials on protocol design.John.   ;  I don't know of any documentation.Just break down what information needs to be sent from the client to the server, and from the server to the client (I'm not too familiar with the rules of poker).Client-to-server:Hello, client introducing himself, desired name, password, etc...Bet, amountCallFoldServer-to-client:BeginMatch, number of players, starting money.BeginTurn, 5 cards.EndTurn, winner, everyones moneyEndMatch, winnerThere's still a few messages missing, but you get the idea. The next step is to give each message an id. Then you can send the data down the socket, I suggest laying it out like:int lengthint messageId<message payload>So for the hello message you'd have something like:21 //length (4 + 1 + 7 + 1 + 8)0 //id7 //uint8 for length of usernameelFarto //username8 //uint8 for length of passwordpasswordI personally have a class that represents my message, that knows how big a message will be, and how to serialise/deserialise it.RegardselFarto   ;  I am thinking even TCP is too low level for what you want to do. In this case you aren't really dealing with real time requirements so maybe used something like a web service. If it is windows based visual studio and wcf will help you out a lot.   