Original Post
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...