CODEWITHSUNDEEP
javanetwork-programming
Eleeist
Eleeist

Reputation: 7041

Desktop program communicating with server

I am in the process of moving the business logic of my Swing program onto the server.

What would be the most efficient way to communicate client-server and server-client?

The server will be responsible for authentication, fetching and storing data, so the program will have to communication frequently.

Upvotes: 0

Views: 102

Answers (2)

Alex Lynch
Alex Lynch

Reputation: 951

it depends on a lot of things. if you want a real answer, you should clarify exactly what your program will be doing and exactly what falls under your definition of "efficient"

if rapid productivity falls under your definition of efficient, a method that I have used in the past involves serialization to send plain old java objects down a socket. recently I have found that, in combination with the netty api, i am able to rapidly prototype fairly robust client/server communication.

the guts are fairly simple; the client and server both run Netty with an ObjectDecoder and ObjectEncoder in the pipeline. A class is made for each object designed to handle data. for example, a HandshakeRequest class and HandshakeResponse class.

a handshake request could look like:

public class HandshakeRequest extends Message {
    private static final long serialVersionUID = 1L;
}

and a handshake response may look like:

public class HandshakeResponse extends Message {
    private static final long serialVersionUID = 1L;
    private final HandshakeResult handshakeResult;

    public HandshakeResponse(HandshakeResult handshakeResult) {
        this.handshakeResult = handshakeResult;
    }

    public HandshakeResult getHandshakeResult() {
        return handshakeResult;
    }
}

in netty, the server would send a handshake request when a client connects as such:

@Override
public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) {
    Channel ch = e.getChannel();
    ch.write(new HandshakeRequest();
}

the client receives the HandshakeRequest Object, but it needs a way to tell what kind of message the server just sent. for this, a Map<Class<?>, Method> can be used. when your program is run, it should iterate through the Methods of a class with reflection and place them in the map. here is an example:

public HashMap<Class<?>, Method> populateMessageHandler() {
    HashMap<Class<?>, Method> temp = new HashMap<Class<?>, Method>();
    for (Method method : getClass().getMethods()) {
        if (method.getAnnotation(MessageHandler.class) != null) {
            Class<?>[] methodParameters = method.getParameterTypes();
            temp.put(methodParameters[1], method);
        }
    }
    return temp;
}

this code would iterate through the current class and look for methods marked with an @MessageHandler annotation, then look at the first parameter of the method (the parameter being an object such as public void handleHandshakeRequest(HandshakeRequest request)) and place the class into the map as a key with the actual method as it's value.

with this map in place, it is very easy to receive a message and send the message directly to the method that should handle the message:

@Override
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
    try {
        Message message = (Message) e.getMessage();
        Method method = messageHandlers.get(message.getClass());
        if (method == null) {
            System.out.println("No handler for message!");
        } else {
            method.invoke(this, ctx, message);
        }
    } catch(Exception exception) {
        exception.printStackTrace();
    }
}

there's not really anything left to it. netty handles all of the messy stuff allowing us to send serialized objects back and forth with ease. if you decide that you do not want to use netty, you can wrap your own protocol around java's Object Output Stream. you will have to do a little bit more work overall, but the simplicity of communication remains intact.

Upvotes: 2

esaj
esaj

Reputation: 16035

It's a bit hard to say which method is "most efficient" in terms of what, and I don't know your use cases, but here's a couple of options:

The most basic way is to simply use "raw" TCP-sockets. The upside is that there's nothing extra moving across the network and you create your protocol yourself, the latter being also a downside; you have to design and implement your own protocol for the communication, plus the basic framework for handling multiple connections in the server end (if there is a need for such).

Using UDP-sockets, you'll probably save a little latency and bandwidth (not much, unless you're using something like mobile data, you probably won't notice any difference with TCP in terms of latency), but the networking code is a bit harder task; UDP-sockets are "connectionless", meaning all the clients messages will end up in the same handler and must be distinguished from one another. If the server needs to keep up with client state, this can be somewhat troublesome to implement right.

MadProgrammer brought up RMI (remote method invocation), I've personally never used it, and it seems a bit cumbersome to set up, but might be pretty good in the long run in terms of implementation.

Probably one of the most common ways is to use http for the communication, for example via REST-interface for Web services. There are multiple frameworks (I personally prefer Spring MVC) to help with the implementation, but learning a new framework might be out of your scope for now. Also, complex http-queries or long urls could eat your bandwidth a bit more, but unless we're talking about very large amounts of simultaneous clients, this usually isn't a problem (assuming you run your server(s) in a datacenter with something like 100/100MBit connections). This is probably the easiest solution to scale, if it ever comes to that, as there're lots of load-balancing solutions available for web servers.

Upvotes: 0

Related Questions