3

I have a multithread server, waiting for socket connections.

The first exchange of message is always of the same type, the clients sends an object with the authentication details(userid/pwd), the server checks it and reply to the server if the authentication has been passed or not.

After this first exchange of messages, the client will send some requests, corresponding to various tasks the server is able to execute. How do i model those eterogeneous requests? In particular my question regards the type of object sent between client and server with InputObjecStream/OutputObjectStream

I had 2 ideas:

  1. Using a "generic message" object, with 2 attributes: a task identifier and an HashMap without generics, able to carry various type of parameters requested for executing the task.

  2. An object for every type of task, this solution is "cleaner", but I don't know how to make the server understand the type of the message received, I thought about a series of object casting of the received message from the client to every possible "specific task message", ignoring the many CastException. It sounds just bad, is there any way to avoid this?

Improve this question
1
  • If you choose route 2, use instanceof. Commented Aug 25, 2012 at 8:51

3 Answers 3

Reset to default
2

Why not combine the two ideas

Start with a common level interface that the server can cast to determine what it should do or now to react.

As the object is passed off to the handler responsible for handling te request can further cast the object (based on a deeper level of interface implementation)

IMHO

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

nice idea, I really like it: it sounds simplier than the Visitor pattern, requiring only 1 additional interface instead of 2 (Element & Visitor) I'm going to read a bit more stuff on visitor design pattern, but I think I'm gonna use this solution
1

The first approach is very generic but will be hard to maintain. After a while you'll notice that you no longer remember what kind of objects should be in this generic map. You'll have to keep the dictionary in sync.

The second approach is much better. Essentially you receive an abstract Request object with various subclasses. The base class can hold some general information. Normally you would use polymorphism and implement the action in each subclass, overriding abstract method from Request class. But you can't because request object would have to hold server-side logic.

The best you can do here is design pattern. With it, for the price of slightly obscuring your code, you'll get very generic and safe design. instanceof tends to be ugly after some time.

Improve this answer

4 Comments

I just read something on the Visitor pattern, I never used it before, in your design the Visitor should be the methods that handle the message and execute the task while the Visited Element is the message?
@mark: yes, abstract Request class has accept(visitor) method and concrete visitor implements different handler methods based on real Request type. No subclassing and instanceof required.
Since I need just 1 concrete visitor with a lot of overloading visit() methods, should I avoid the visitor interface and work directly with the concrete visitor? It seems useless to me
@mark: yes, there is no point in having Visitor interface and concrete implementation. You can split them once you need them.
0

What you could do is use XML messages for the communication. You could prepend in the first bytes an indication for which XML object the message should be mapped and on reception of the message, just check these bytes find the indicator, and use the rest bytesequence to marshal the bytes to XML object (using JAXB or SimpleXML or DOM or anyother xml parser) XML is very verbose and you could use it here to encapsulate your messages.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.