Streaming data in Java: RMI vs Socket

Question

I have a server that needs to stream data to multiple clients as quickly as possible in the Observer pattern.

At least 200 messages need to be sent to each client per second until the client disconnects from the sever, and each message consists of 8 values of several primitive types. Because each message needs to be sent as soon as it is created, messages cannot be combined into one large message. Both the server and the clients reside on the same LAN.

Which technology is more suitable to implement streaming under this situation, RMI or socket?

Answer 1

The overhead of RMI is significant so it would not be suitable. It would be better to create a simple protocol and use sockets to send the data.

Depending on the latency that is acceptable you should configure socket buffer sizes and turn off Nagle algorithm.

Answer 2

I would not use RMI for this, RMI is just there for Remote Method Invocation, ie when the client wants to execute a method (ie some business logic) on the server side.

Sockets are OK for this, but you might want to consider JMS (Java Messaging Service) for this specific scenario. JMS supports something called a Topic, which is essentially a broadcast to all listeners interested in that topic. It is also generally optimised to be very fast.

You can use something like Apache ActiveMQ to achieve what you want. You also have lots of options such as persistence (in case the queue goes down messages remain in queue), message expiry (in case you want the messages to become outdated if a client does not pick them up) etc.

You can obviously implement all this using normal Sockets and take care of everything yourself, but JMS provides all this for you. You can send text or binary data, or even serialized object (I don't personally recommend the latter).

Answer 3

RMI is a request/response protocol, not a streaming protocol. Use TCP.