SocketServer, how to know the object type from getInputStream

[John_Woo]

Hi,

Same socket server, communicates with different multi socket clients
some of which send to
socket a java object, and others send just a DataOutputStream, ex

some clients:
DataOutputStream os = null;
os = new DataOutputStream(smtpSocket.getOutputStream());

String msg = (new BufferedReader( new
InputStreamReader(System.in)).readLine())+"\n";
if (msg!=null) os.writeBytes(msg);

other clients:
ObjectOutputStream oo = null;
....
oo.writeObject(new MyObject());

I'm wondering, how does the server know what type the inputStream sent
from client is?

if that's of type
BufferedReader is;
is = new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));

then it's easy to print out or easy to send back a string.

if that's of customized Object type, then the server has something else
to do/respond.

Any idea?

 

[Vincent van Beveren]

Any idea?

You seem to want to use two incompatible streams. If you wish to send
data and Strings over a connection, use the ObjectInput/OutputStream. IT
has a read/writeUTF method. It doesn't know what type you send (object /
of UTF).. you'll have to read the right thing at the right moment. For
example, the protocol might be <cmd> <array of objects> where cmd is a
UTF string. Then you would first read a String, and then read an object.

Vincent

 

[John_Woo]

You seem to want to use two incompatible streams. If you wish to send
data and Strings over a connection, use the ObjectInput/OutputStream. IT
has a read/writeUTF method. It doesn't know what type you send (object /
of UTF).. you'll have to read the right thing at the right moment. For
example, the protocol might be <cmd> <array of objects> where cmd is a
UTF string. Then you would first read a String, and then read an object.

Vincent

Thanks, for the idea.
But still, I couldn't know how to separate the string and object. The
read/write UTF is providing string, doesn't tell the type of object. Do
you have more info?

John

 

[Martin Gregorie]

Thanks, for the idea.
But still, I couldn't know how to separate the string and object. The
read/write UTF is providing string, doesn't tell the type of object. Do
you have more info?

You need to design a protocol to do this.

You might decide that every object is preceded by a message that gives
its type and any other necessary information. You may then find you need
additional messages that do not precede an object, such as messages that
identify the client or say that the client is ending the session. You
may want the server to send a message back after it has received each
object to confirm that the object is OK. So, you need to design a
structure for the messages (I like to use an ASCII string containing
comma separated fields) that is easy to recognize, decode and validate.

Write it down. Check that all possibilities are covered. Make sure that
errors are recoverable and that there is no possibility that the
protocol can get stuck.

Then, and only then, start coding. Make sure your clients and servers
can produce diagnostic traces of the running protocol. You'll need that
for certain.