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)?

"Zalabado" <zala@xxxxxx> wrote in message
news:gm6k7d$jov$1@xxxxxx

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

"Alberto Poblacion" <earthling-quitaestoparacontestar@xxxxxx> wrote
in message news:eW9iDuShJHA.4880@xxxxxx

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

"Alberto Poblacion" <earthling-quitaestoparacontestar@xxxxxx> wrote
in message news:eW9iDuShJHA.4880@xxxxxx

> "Zalabado" <zala@xxxxxx> wrote in message
> news:gm6k7d$jov$1@xxxxxx

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

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!

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 )


"Zalabado" <zala@xxxxxx> wrote in message
news:gm6k7d$jov$1@xxxxxx

> 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)?
>

"Zalabado" <zala@xxxxxx> wrote in message
news:gm6p6s$33o$1@xxxxxx

> "Alberto Poblacion" <earthling-quitaestoparacontestar@xxxxxx> wrote
> in message news:eW9iDuShJHA.4880@xxxxxx
> 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.

On Mon, 02 Feb 2009 04:32:10 -0800, Zalabado <zala@xxxxxx> wrote:

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

It has everything to do with it. Socket i/o is strictly based on bytes.
You can only send bytes and you can only receive bytes. If you have some
other data structure to send and receive, you need to convert it to bytes,
and then convert it from bytes. Which, as you have already seen, is
exactly what serialization is about.

Now, there are other ways to go about it. You can define your own way to
package up the data, and that may well produce fewer bytes to send than
using the built-in serialization. But at some point you have to convert
the data to bytes so that it can be sent via the Socket, and then convert
the bytes back to your desired data structure.

Note that .NET includes a couple of features meant to abstract away from
the Socket class: remoting, and WCF. Unfortunately, I don't know a lot
about either so I can't really answer questions about them, but they
provide a way for your program to simply deal with objects and not worry
about the serialization part. Using either of those, you won't even use
the Socket class directly.

Pete