Objects in Sockets
Hi,
I'm writing a server <-> client application and I have a problem while sending Objects.
Generally, everything is fine as far as I don't want to send object back and forth. My problem by example:
- Server creates an object for instance myObject = new MyObject();
- Server puts an this object on a list myObjectList.add(myObject);
- Server sends the Object to the client via writeObject
- Client recives the package myObject = (myObject)input.readObject();
- Client sets a text in the object myObject.setText("Hello server");
- Client sends the object back to the server
- Server gets the object myObjectFromClient = (MyObject)input.readObject();
and here comes my problem out. Server will be reciving many such objects and he is going to check, which response did he get, but when I'll do a contains() check on a list of MyObjects: myObjectList.contains(myObjectFromClient); I'll get a false in result :(
Is there any way to recognize same objects when using sockets? one and obvious method is to set a field in an object with an ID and then I'll be able to recognize it when it gets back, but looks very non proffesional to me...
Thanks in advance
Maciej
[1254 byte] By [
Rukh83a] at [2007-11-27 3:30:17]
# 1
have you tried instanceof?if(obj instanceof className) {//Do this..}
# 2
Yes, I use the instanceof in the whole program, but instance of an object is an information that this object is from that exact type, it wont tell you that this object is exact the same instance of this object.. :/
# 3
in other words, you can check using instance of if
if(object instanceof className)
but you cant check if
if(object instanceof object)
in the way that you would like that this is the same object that you send away earlier.
the problem is that when the object cames back and I deserialize it in fact I create a new object and it has its own allocation in memory and I cant use the '==' operator to verify which object came back.
Message was edited by:
Rukh83
# 4
>
> Is there any way to recognize same objects when using
> sockets? one and obvious method is to set a field in
> an object with an ID and then I'll be able to
> recognize it when it gets back, but looks very non
> proffesional to me...
Yes, but sending objects at all, rather than messages (which contain data) looks very unprofessional to me.
So set the id.
# 5
> Yes, but sending objects at all, rather than messages
> (which contain data) looks very unprofessional to
> me.
>
> So set the id.
And what are your suggestions for next time I'll use sockets? Send only String messages and catch them with String.equals() ?
Its a bit problematic when I need to send for instance players highscores, or even login and password. In such case I have to separate a String, for instance: "login|password" and then tokenize it on the other side and this looks nasty. And in the next step, who knows that you send a login and a password, maybe it was something else.. so I need another 'field' in my String: "loginInformation|login|password", and it gets worse and worse when it cames to bigger packs of information.
# 6
> > Yes, but sending objects at all, rather than
> messages
> > (which contain data) looks very unprofessional to
> > me.
> >
> > So set the id.
>
> And what are your suggestions for next time I'll use
> sockets? Send only String messages and catch them
> with String.equals() ?
Define a protocol.
> Its a bit problematic when I need to send for
> instance players highscores, or even login and
> password. In such case I have to separate a String,
> for instance: "login|password" and then tokenize it
> on the other side and this looks nasty. And in the
> next step, who knows that you send a login and a
> password, maybe it was something else.. so I need
> another 'field' in my String:
> "loginInformation|login|password", and it gets worse
> and worse when it cames to bigger packs of
> information.
Defining the protocol of the message is part of the design for creating the communication layer.
And I work with messages that have hundreds of fields and where the number of messages have probably reached about 50 so far. And yet it doesn't bother me at all that there is a sharp demarcation between the communcation layer(s) and the rest of the application(s).
# 7
> Define a protocol.
unfortunately I don't understand what do you mean by creating a protocol:/ Can you say it in some other words or somehow refer to that what I wrote below, who knows maybe I somehow used your idea.
In my version of the communication I have a main Message Class that I use as a message and then few Request and Response messages that extend this Message Class and I send those Request/Response packages and they contain data...
# 8
> > Define a protocol.
>
> unfortunately I don't understand what do you mean by
> creating a protocol:/ Can you say it in some other
> words or somehow refer to that what I wrote below,
> who knows maybe I somehow used your idea.
I need to send data via a socket. So I define a protocol for a message.
It could be like the following
Request
1. Text: MESSAGE001
2. data length: big endian 4 byte value representing integer
3. data: bytes (data) which has a length represented by <data length>
Response
1. Text: MESSAGE001
2. 1 byte error code: error code (zero is success)
3. data length: big endian 4 byte value representing integer
4. data: bytes (data) which has a length represented by <data length>
This contains the response as a text value (SUCCESS for zero, otherwise detailed info about error.)
This defines a request and response for the communication layers.
Other layers are responsible for correctly using the communication layer to send requests and receive the response.
More complicated messages and layers are possible.
> In my version of the communication I have a main
> Message Class that I use as a message and then few
> Request and Response messages that extend this
> Message Class and I send those Request/Response
> packages and they contain data...
For me those are data.
