I''ve done tons of software development over the years but I''m new to Java and I''ve never tried to build a multi-player game before so I''ve got some questions about what technique to use for communications between the players. I''ve come up with several alternatives and I''m keen to get others thoughts on which one would be the best or is there another that I''ve not thought of. TCP/IP or UDP ============= Pretty obvious because it''s what most Internet games do right now. However a lot of games get to rely on a third party library or DirectPlay to hide the nastiness of lost packets, retries, etc. Pros: Fast and down at the bare wire. Works for most people who want to play even if they are in the same office. Cons: Won''t work for direct connections (e.g. serial). Low level IP work can be unpleasant to get working perfectly and is definitely no fun to write. HTTP ==== If I could embed an HTTP server in each end they could communicate through simple requests for pages, posting XML and receiving it to communicate with each other. Pros: Pretty darn simple IF there is an easy to embed HTTP server that can be put into the game. Also, most firewalls don''t block HTTP traffic. Cons: Still have to deal with timeouts and retries (ala. TCP/IP and UDP). If there is no easy to embed server, this would probably not be worth the effort. Java Shared Data Toolkit ======================== Hides all the nasty details of communication at all by keeping data structures in each program in sync with one another. To each program it appears that it is only dealing with changing data. Pros: Somebody else handles the nitty gritty details and they have even come up with something that can work with a variety of communication protocols. Cons: In the beta 2.0 version setup seems to be a bear. My first try didn''t work and I need to try it again. I''m worried that I could not practically ask people to do anything that was more complicated than typing in an IP address (and hopefully if I could eventually get a lobby together, less than that). Jabber Messages =============== Use the protocol that is being set up for buddy lists and chat to communicate between the two ends. See Jabber.org for details. Pros: Already exists and I can get Java sample code for the clients to communicate with. Provides natural extensions to tell you when favorite people are available to play and for people not even in your game to chat with you while you play. Cons: Server development, heck, all development on the project has been glacially slow. No peer to peer communication is possible which implies that servers must always exist for players to communicate through (a real drag when the people who want to play are all in one office and they could care less about the server). RMI === Remote method calling from one machine to the other to communicate back and forth. Pros: Built into Java, well tested. Hides communication nastiness? Cons: Don''t know about firewall friendliness. How hard will it be for users to set up their machines so others can connect to them to play a simple game? Anything else people can think of...

Well many of the alternatives you''re looking at all involve a great deal of protocol overhead. This is a bad thing for games. I personally thing that working directly with TCP/IP or UDP/IP is currently the best choice.

Some comments:

TCP/IP
------------
Java has a beautiful interface to the TCP/IP and UDP/IP. So for me the low level IP work is far from unpleasent to get working perfectly. Especially when I think of the pain it is in pure C. Also none of the Java network functions works on direct connections like serial. So you might as well not list that as a con, or list it for all.
Also most serial connections you can assign IP numbers to both ends, in effect making it transparent to the IP stack.

HTTP
-----------------
Why oh why oh why.
The protocol overhead would be a bear. You''re layering a connection oriented activity (gaming) over a connectionless protocol (HTTP) on top of a connection oriented protocol (TCP). Why would you want to handle with so many reconnects to each client?

Java Shared Data Toolkit
------------------------
Haven''t worked much with this. Never got the patience to get past the setup.

Jabber Messages
---------------
Ok as additional bonus kind of protocol, but I think the server thing would be a deal breaker for many people.

RMI
---
Again RMI, as far as I know, reconnects to the client for every transaction. This kind of overhead doesn''t sound happy. Also with RMI you call the function and get a return value. I believe this block the program until a return value is received. So if you do alot of small calls this can stutter your game. If you do a single big call, you''d probably send excess information every invocation.

FTP
---
Many of the advantages and disadvantages of HTTP. However there is always a control channel open, which could make life a lot easier for short control commands.

I''m agreeing with SiCrane here. Writing your own sort of protocol would be the best thing. You don''t want an HTTP server because it is built to hand off requests and start listening for more right away, connectionless like si said. There are many client/server examples in the java books i''ve seen. Just open a socket on both ends and make your own kind of network events. If you really think that people are gonna use a null modem and serial cables to play your game, you can look into the Java Comm API to do the same sort of thing.

I''m stupid, I should have said this from the start. The game I''m working on is basically turn based. Things like HTTP protocol overhead and such aren''t as important to me as ease of implementation. Almost any normal turnaround time will be completely swallowed up in the waits that the players themselves impose on the game.