0

I am currently decide what kind of communication method/network protocol I am going to use for a new project. What I can tell you about this project is that: - It is Android/java based, using X amount of Android devices - These devices should be able to send strings to each other over a local network. We are talking about small strings here. Small as in less than 100 characters. - The amount of packages/transmissions being sent can vary "A LOT". I can't say how much unfortunately, but the network protocol needs to be as scalable as possible.

I have researched different kinds of possible solutions and is now deciding wether to use "Sockets" or "RMI"

As I have understood about RMI:

  • It is easier than Java sockets to implement and maintain (smaller amount of code)
  • It is "a bit slower" than sockets, as it is a new "layer" build on top of Sockets
  • There may be some scalability issues (if this is true, how "serious" is it?) as it creates a lot of new sockets, resulting in Exceptions.

Obviously the system needs to run as smooth as possible, but the main objective is to make it scalable so it can handle more Android devices.

EDIT: The system the system is not "peer-to-peer". All of the android devices should be able to be configured as the server.

SomeDude
  • 15
  • 1
  • 6
  • The last time I looked at RMI, it was strictly one connection per thread. If you are looking to write a high performance server, this isn't the way to go. Use sockets and asynchronous I/O. Maybe look into Google Protocol Buffers. – mpontillo Feb 12 '14 at 10:46
  • @Mike One connection per client thread per target. Why exactly would you need more? – user207421 Feb 12 '14 at 10:48
  • @EJP might be OK for small amounts of clients. See http://www.kegel.com/c10k.html. In particular, http://www.kegel.com/c10k.html#threaded – mpontillo Feb 12 '14 at 10:51
  • @Mike I don't see RMI mentioned on that page. Are you referring to the server end, or the client end? – user207421 Feb 12 '14 at 10:52
  • @EJP, I was just talking about general scalability concepts, not RMI in particular. If we're only talking about a few devices talking to each other, it won't be an issue. But when I see terms like "scalability" and "performance" I think "asynchronous events", not "let's block on `read()` and create a thread per client" – mpontillo Feb 12 '14 at 10:55
  • 1
    Based on your description I would rather worry how you are planning to achieve peer-to-peer communication with Android devices. You'll need a central message hub which dispatches the messages. That means you'll need durable connections from Android to that server. That pretty much excludes RMI, which is strictly request-response. A good choice could be WebSockets. – Marko Topolnik Feb 12 '14 at 11:02
  • @MarkoTopolnik I am not planning to achieve peer-to-peer. It should be client-server, sorry about the unclear question. – SomeDude Feb 12 '14 at 11:32
  • `All of the android devices should be able to be configured as the server.` I don't think that's possible. – Marko Topolnik Feb 12 '14 at 11:32
  • $MarkoTopolnik Why not? I don't mean that theres should be more than one server at the time, but all of the devices will have the opputunity to choose to be client/server at startup. – SomeDude Feb 12 '14 at 11:35
  • Because your Android device does not have a stable public IP + DNS entry. – Marko Topolnik Feb 12 '14 at 13:23
  • @Mike The Java part of that page was last updated in *2001.* See [this thread](http://stackoverflow.com/questions/3129608/is-there-any-modern-review-of-solutions-to-the-10000-client-sec-problem) for a more current review of it and the C10K topic in general. The thinking for some years has been that threaded blocking I/O is the solution, not the problem. – user207421 Feb 13 '14 at 01:02
  • @EJP I looked at the thread. But I don't buy the "we don't care if it's inefficient, just throw more servers at it" argument. Here's a counterexample for you: [nginx](http://wiki.nginx.org/), which uses the opposite (and more defensible, IMO) strategy. – mpontillo Feb 13 '14 at 01:56

2 Answers2

0

None of your concerns are the real issue, in my view.

RMI has a pre-defined protocol, raw sockets do not.

If you use raw sockets, you have to do all the work to define what messages and protocols are exchanged by client and server.

There are so many good existing protocols (RMI, HTTP, etc.) that I'd wonder why you feel the need to invent your own again.

Android devices communicating over HTTP - tell me why it won't be fast or scalable enough. HTTP is good enough for the Internet - why not you and your solution?

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • HTTP and RMI don't exactly stand shoulder-by-shoulder. With HTTP as transport you still need serialization/deserialization that you get out of the box with RMI. Not that I would recommend RMI (due to the pitfalls of Java Serialization). – Marko Topolnik Feb 12 '14 at 11:00
  • RMI means Java client and server if I understand it right. HTTP is more open and language agnostic. Mapping is hardly the biggest hurdle. I'd recommend Spring web services. – duffymo Feb 12 '14 at 11:21
  • `Mapping is hardly the biggest hurdle`---not to OP, if he is at the level of considering RMI vs. raw Sockets as alternatives. – Marko Topolnik Feb 12 '14 at 11:24
  • I think it's clear that the OP is confused about his/her concerns and what is important. Guilty of premature optimization, in my view. Build something, measure, test scalability, and decide if it's acceptable. – duffymo Feb 12 '14 at 11:26
  • 1
    I think he is not even aware of doing premature optimization :) I second the Spring recommendation, but I'd go with Spring REST and JSON for a start. – Marko Topolnik Feb 12 '14 at 11:27
  • Thanks for all your answers. @MarkoTopolnik What's your argument for using REST and Json instead of Sockets/RMI? – SomeDude Feb 12 '14 at 11:54
  • I agree-Spring/REST is a far better choice that either sockets or RMI. – duffymo Feb 12 '14 at 13:08
  • REST and JSON because the Internet is based on HTTP and JavaScript in the browser. It's working for everyone else; it will for you, too. – duffymo Feb 12 '14 at 13:09
  • In addition to duffymo's arguments, Spring has excellent support for REST and JSON, including very simple transformation between objects and JSON strings. – Marko Topolnik Feb 12 '14 at 13:22
0

I would suggest you to expose some kind of webservice (SOAP or REST) in your application server. For example, people frequently expose their data to mobile devices as a REST webservice API returning some kind of JSON format in order to make it easier to marshal it again in the client device.

This way you take profit of the underlying implementation of HTTP communication in every application server; any other way, you would have to write your own worker thread pool using nio primitive operations in order to achieve performance... Not a thing to be done in a real production environment - maybe in an academic one?

Jorge_B
  • 9,712
  • 2
  • 17
  • 22
  • 1
    And if I ever considered such a thing, answering your question, I would write it over the socket layer... I am not fond of the little experience I have had with RMI :( – Jorge_B Feb 12 '14 at 10:57
  • +1 I second that :) To compare notes, could you just briefly tell me what was your major gripe with RMI? – Marko Topolnik Feb 12 '14 at 11:09
  • 1
    I know it is just an opinion, but I found performance really poor at the time (I am talking about 2000-2001 implementations of RMI). And its relative ease of development is not worth today (these days you can annotate something as @WebService and some automated build tool will generate you something cute) – Jorge_B Feb 12 '14 at 11:14
  • 1
    2000-2001 implementations are so old, as are the JVMs they were implemented on, to be almost irrelevant to the discussion. – duffymo Feb 12 '14 at 11:22