Socket programming - how to identify accepted data?

[Zalabado]

Hi!

I am a newby in socket programming (C#) and after a lot of googling I
succeeded in connecting and sending (asynchronous) a data over socket
between a server and client
However, I would like to accept data via socket (e.g. from client) but for a
few different purposes (e.g. textmessage, login, password) and therefore i
would like to know what am i accepting (id, textmessage, login, password)...

Well, the question is: How to identify what kind of data am I accepting (id,
textmessage, login, password)?

 

[Alberto Poblacion]

I am a newby in socket programming (C#) and after a lot of googling I
succeeded in connecting and sending (asynchronous) a data over socket
between a server and client
However, I would like to accept data via socket (e.g. from client) but for
a few different purposes (e.g. textmessage, login, password) and therefore
i would like to know what am i accepting (id, textmessage, login,
password)...

Well, the question is: How to identify what kind of data am I accepting
(id, textmessage, login, password)?

The socket will merely deliver a stream of bytes. It is up to you to
define your own convention as to how you are encoding information in those
bytes. For instance, you may decide that the first byte represents the type
of data (1=textmessage, 2=login, etc), then the next two bytes are an
integer representing the length of data, and then the next 'n' bytes (as
encoded in the preceding variable) are the content of the message itself. As
a sanity check, you may append a final byte or bytes with a 'magic value'
(or a checksum) to verify that your encoding and decoding have worked
properly. All of this can, of course, be modified as needed depending on the
information that you are transmitting. It may be useful to apply one of the
Serialization mechanisms provided with the Framework to encode the various
types of objects that you are transmitting.

 

[Zalabado]

cut

The socket will merely deliver a stream of bytes. It is up to you to
define your own convention as to how you are encoding information in those
bytes. For instance, you may decide that the first byte represents the
type of data (1=textmessage, 2=login, etc), then the next two bytes are an
integer representing the length of data, and then the next 'n' bytes (as
encoded in the preceding variable) are the content of the message itself.
cut
It may be useful to apply one of the Serialization mechanisms provided
with the Framework to encode the various types of objects that you are
transmitting.

Well, according to google , Serialization is the process of converting
complex objects into stream of bytes for storage. Deserialization is its
reverse process, that is unpacking stream of bytes to their original form.

Therefore, i dont get it what the serialization has to do with convention of
information encoding that is defined by me...

An additional explanation or example would be great

Thanks in advance!

 

[Jamesb]

The socket will merely deliver a stream of bytes. It is up to you to
define your own convention as to how you are encoding information in those
bytes. For instance, you may decide that the first byte represents the
type of data (1=textmessage, 2=login, etc), then the next two bytes are an
integer representing the length of data, and then the next 'n' bytes (as
encoded in the preceding variable) are the content of the message itself.
As a sanity check, you may append a final byte or bytes with a 'magic
value' (or a checksum) to verify that your encoding and decoding have
worked properly. All of this can, of course, be modified as needed
depending on the information that you are transmitting. It may be useful
to apply one of the Serialization mechanisms provided with the Framework
to encode the various types of objects that you are transmitting.

I did something similar but probably more amateurish, in that I sent
information between my client and server as a simple array- the first item
was always a string containing a code, so the receiving app would cast the
first item in the array to a string, check the code, and then deal with any
following items as necessary. This was usign remoting and events though, but
I imagine the same process could be applied with socket data.

The sanity checks and stuff listed above are probably a good idea though!

 

[Bill Richards]

Hi Zalabado,

as Alberto pointed out, the socket is merely a mechanism by which a message
is transported, and therefore it presupposes no messaging protocol.

The protocol is for you to specify, or maybe you would find it easy to use
a pre-existing protocol. Within healthcare, for example a protocol called
HL7 is used to describe HOW the data look when they are transmitted across
the wire.

I believe that Alberto was trying to tell you that you can simply use your
..net objects, use the .net provided serialization mechanisms to de/serialize
these objects and transmit those objects between your client and server.
Obviously if you do this you will need to have the objects defined within a
common assembly which can be deployed to both your server and your client.

Good luck )

 

[Alberto Poblacion]

in message Well, according to google , Serialization is the process of converting
complex objects into stream of bytes for storage. Deserialization is its
reverse process, that is unpacking stream of bytes to their original form.

Therefore, i dont get it what the serialization has to do with convention
of information encoding that is defined by me...

No! Not necessarily for storage. Serialization converts your complex
objects into a Stream of bytes, which you can certainly send to storage, but
you can also pump into a Socket, which will transmit them into the
destination socket, where you can then Deserialize them back into a
"replica" of the original objects. The Binary Serializer in the .net
Framework encodes the type of object into the stream that it produces, and
the deserializer throws an exception if you try to "extract" the wrong type,
so it serves as a sanity check to verify that the convention you used to
encode the type of object into your stream is working correctly.