SocketServer, how to know the object type from getInputStream

Discussion in 'Java' started by John_Woo, Jul 24, 2006.

  1. John_Woo

    John_Woo Guest

    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?

    --
    Thanks
    John
    Toronto
     
    John_Woo, Jul 24, 2006
    #1
    1. Advertising

  2. >
    > 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
     
    Vincent van Beveren, Jul 24, 2006
    #2
    1. Advertising

  3. John_Woo

    John_Woo Guest

    Vincent van Beveren wrote:
    > >
    > > 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


    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
     
    John_Woo, Jul 25, 2006
    #3
  4. John_Woo wrote:
    > Vincent van Beveren wrote:
    >>> 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

    >
    > 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.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Jul 25, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joana
    Replies:
    5
    Views:
    5,476
    John C. Bollinger
    Sep 16, 2003
  2. b83503104
    Replies:
    1
    Views:
    28,304
    John C. Bollinger
    Dec 1, 2003
  3. igoR Buttler
    Replies:
    1
    Views:
    12,156
  4. Syed Ali
    Replies:
    1
    Views:
    838
    kpl_pl
    Jul 20, 2007
  5. Andries

    I know, I know, I don't know

    Andries, Apr 23, 2004, in forum: Perl Misc
    Replies:
    3
    Views:
    240
    Gregory Toomey
    Apr 23, 2004
Loading...

Share This Page