Alternative to Sockets

[Kuroshi]

I made a program using Sockets, pretty interesting, but I have found some "problems" that bother me, my game is threaded and in its run method it has a lot of if statements for the different behaviors when it receives a certain String from the server. Is there any other way to make the clients do something beside sending a String or integer? I would loke to know.

Another question is that I am experiencing some problem while using sockets to know when the client has closed the connection, when he/she closes the program HIS/HER connection is closed, but the connection from the server to him/her is not, so I said, pretty simple, lets send a String telling the server that the client is going to close the window, the receiving end in the server is inside a Timer, it works fine, but for some reason, the other .readUTF() do not work when this one is running, even after stopping this Timer.

Thank you for reading.

[jwenting]

Sure, you could use a library that uses another networking stack, but you'd be limiting your audience to people using networks using that stack.

If you're programming raw sockets, you can only ever send bytes. Java also lets you send Strings and integers, because it handles the conversion to bytes for you.
You can of course send anything by serialising it, that's one of the things serialisation was created for.

Pretty much every other networking library you could bolt onto any programming language will work on top of sockets, so you'd be using them anyway :)

[JamesCherrill]

RMI provides a high-level interface for remote method invokation (via sockets, of course) so the server can "directly" call methods on the client (and v.v.), but there's quite a learning curve if you don't need all its facilities.

Sending a String or int to invoke specific functions is a pretty standard thing to do. Purists may prefer to send an enum or an Action.

I find this process works cleanly for closing a bi-directional link:

client wants to close connection:
client sends logoff message to server and exits its read wait loop
server receives message and exits its read loop and closes connection
client ignores any subsequent exceptions related to the connection.

and the same v.v. if the server wants to close.

[JamesCherrill]

OR...
You can do a "roll-your-own" mini-RMI using Reflection if you don't mind compromising a bit on compile-time checking and security. It goes like this:

Send via the Socket a command String that is the name of a public void no-params method in the receiver's class.
At the receiver use Reflection to get and execute the named method.
That way you can hook directly from command Strings to callable methods without any nested ifs or switches. It's also really easy to add new commands/methods.

String command = ...

Method m = getClass().getDeclaredMethod(command);
m.invoke(this);

Biggest problem is that this exposes all the classes public void no-args methods to external execution, which may or may not be a security concern. You can obviate this by adding a custom annotation to the callable methods and checking for that annotation before invoking. (This is a part of Java that I'm particularly interested in, so if you want to pursue it further I'd be happy join in)

[mKorbel]

aplologize me for hiJacking this thread but,

@ jwenting wrote

If you're programming raw sockets, you can only ever send bytes. Java also lets you send Strings and integers, because it handles the conversion to bytes for you.

are you sure that that is valid for Non-ACSII chars, maybe then I something ***, or I'm wrong isn't there something as InputStream...

[jwenting]

aplologize me for hiJacking this thread but,

@ jwenting wrote

If you're programming raw sockets, you can only ever send bytes. Java also lets you send Strings and integers, because it handles the conversion to bytes for you.

are you sure that that is valid for Non-ACSII chars, maybe then I something ***, or I'm wrong isn't there something as InputStream...

yes, I am sure. Everything gets translated to bytes as only bytes can get sent over the line :)

The Stream reads the bytes but doesn't know what to do with them. If you expect Strings, wrap the Stream in an InputStreamReader.

[Kuroshi]

Thank you for the answers, I will have a look into RMI :).