4

What are some open source client-server projects which might be best to look at and mimic their code organization style?

Java is preferred but not required.

Related:

I'm still trying to determine an answer to my question from a few minutes ago, "Should client-server code be written in one 'project' or two?" and I think it would benefit me to see how other projects organize their code (and hopefully deduce the pros and cons of why they chose to do it that way).

Community
  • 1
  • 1
Ricket
  • 33,368
  • 30
  • 112
  • 143
  • 1
    Why aren't you just editing your original question? – Bill the Lizard Mar 25 '10 at 16:37
  • This is an entirely different question. There are other issues besides division of code into one or two projects. I only mentioned the previous question because it was my inspiration for this one. – Ricket Mar 25 '10 at 21:53
  • @Ricket: Fair enough. I'm rearranging a bit. Check my edits and just revert them if you disagree. – Bill the Lizard Mar 26 '10 at 00:09
  • @Carsten: By thin client do you mean a server that utilizes an existing technology such as telnet? I was thinking something with a rich client and server pair. – Ricket Mar 26 '10 at 00:52
  • Rich client: usually a stand-alone application with at least some internal logic, e.g. gets data from the server, but does most of the processing itself. Thin client: Almost all business logic is executed on the server, only the result is sent to the client for display; e.g. often seen in Javascript clients running in a web-browser. Usually people would organize their code differently based on this distinction. – Carsten Mar 28 '10 at 23:13

2 Answers2

2

Well since nobody else dares answer, here are a couple, though I'm not sure they are good examples to go by: (disclaimer: I have only looked into the source code of a few of these)

  • Cube game & 3D engine, a multiplayer FPS with unique multiplayer editing capabilities, written from scratch using OpenGL and SDL
  • Cube 2: Sauerbraten, same as Cube with slightly more developed features
  • Planeshift, an open-source MMO
  • Red Dwarf Server, a Java server application primarily targeted at online games and MMOs; only comes with small example clients
Ricket
  • 33,368
  • 30
  • 112
  • 143
  • Google Web Toolkit puts the client and server in the same project but in different packages, but it enforces client/server separation at compile time. For something where you don't have a fancy custom plugin enforcing this, I think the best option is to have the server include the client so that it has access to client code but not vice versa. – Ricket Jul 05 '11 at 10:55
1

I dont know if this is too late but heres what i have to say about it, i usually keep the server and the client in the same project just incase they both need access to a class. If you are still interested in some example code, ive been doing networking for 5 years+ and i have plenty of example code if youre interested.

gsfd
  • 1,070
  • 2
  • 12
  • 17
  • Playing devil's advocate, "in case they both need access to a class" is not a definitive reason to put the code in the same project. A project can be a dependency of another project, or can be compiled to a library which the other project includes in its classpath. Especially since you don't want to ship with server code in your client, I think it makes sense to separate them out so that the server project includes the client code but not vice versa, right? – Ricket Jul 05 '11 at 10:53
  • True, but i like to keep them together untill i release the final product, i would seperate them before i released it to save space because the client doesnt need access to the server classes, but when im developing the program i usually keep them together. – gsfd Jul 05 '11 at 17:19
  • That seems like it could be difficult, especially if more and more coupling problems are introduced over time and then, come release time, you have a big mess on your hands and have to sift through it and decouple manually. I would prefer immediate, compile-time feedback to deploy-time cleanup, since it should never be the case that the client uses server-specific code. It's definitely a matter of opinion though, and it's likely you have more actual experience with it than I do. – Ricket Jul 05 '11 at 18:42
  • Well i think its a good idea to keep them in the same project untill you release it because sometimes the server and the client need to share a class, like if you had a checkers game and both the server and the client needed an instance of player to keep track of the pieces each player owned, things like that. – gsfd Jul 05 '11 at 18:46