Seralisation the final question

[Daniel]

Hi

i want to be able to check if information read that came from over a socket
is serilisable, if it isnt i want to handle it differently. Basically i am
trying to make a generic receivedata function that i can send any form of
data over the wire too and it will handle it appropriately.

I know i could do a try catch on a serilisation exception but i dont think
this is a good way to check as other things could cause such an error.

I did think of writing into the first 4 bytes of the send stream an
indenitifier for the response, then the slient can read those bytes and
decide, but again it starts to become less generic. Ideally i would like
anyone to send any info and i can handle it

Any ideas?

Also i am stuck on a scenario where i send data and cant proceed until i get
a response. One of my functions on the client fires a request but if the
client continues before getting a response it will crash. If i get it to
wait i end up poling and everything freezes for a second. I was thinking of
moving my interface logic and my actual application logic to 2 separate
threads. Then i can make the app logic wait while the sent message waits for
a reply, meanwhile the interface thread continues and i get no apparent
freeze. But i am sure this is not good for performance or is this ok?

thanks

[Nicholas Paldino [.NET/C# MVP]]

Daniel,

I would consider your objects to be messages. Either that, or you have
a wrapper object that has a reference to the object being serialized, as
well as any other information that needs to be sent along (like the status
code).

Then, you would send the length across the wire first, so you know how
many bytes to read.

With serialization, you just need a byte array that represents the
serialized instant. It doesn't matter wha the transport mechanism is.

I would also recommend having each of those types implement an interface
which will make accessing the objects in a consistent way easier.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Daniel" <Da*****@vestryonline.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Hi

i want to be able to check if information read that came from over a
socket is serilisable, if it isnt i want to handle it differently.
Basically i am trying to make a generic receivedata function that i can
send any form of data over the wire too and it will handle it
appropriately.

I know i could do a try catch on a serilisation exception but i dont think
this is a good way to check as other things could cause such an error.

I did think of writing into the first 4 bytes of the send stream an
indenitifier for the response, then the slient can read those bytes and
decide, but again it starts to become less generic. Ideally i would like
anyone to send any info and i can handle it

Any ideas?

Also i am stuck on a scenario where i send data and cant proceed until i
get a response. One of my functions on the client fires a request but if
the client continues before getting a response it will crash. If i get it
to wait i end up poling and everything freezes for a second. I was
thinking of moving my interface logic and my actual application logic to 2
separate threads. Then i can make the app logic wait while the sent
message waits for a reply, meanwhile the interface thread continues and i
get no apparent freeze. But i am sure this is not good for performance or
is this ok?

thanks

[Mike]

"Daniel" <Da*****@vestryonline.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Hi

i want to be able to check if information read that came from over a
socket is serilisable, if it isnt i want to handle it differently.
Basically i am trying to make a generic receivedata function that i can
send any form of data over the wire too and it will handle it
appropriately.

I know i could do a try catch on a serilisation exception but i dont think
this is a good way to check as other things could cause such an error.

I did think of writing into the first 4 bytes of the send stream an
indenitifier for the response, then the slient can read those bytes and
decide, but again it starts to become less generic. Ideally i would like
anyone to send any info and i can handle it

Any ideas?
It can't really be "generic" -- it can only handle the instances for which
you anticipate and senders agree to.
You need to send the length with any message (this is a stream), and I'd go
for the ID over the partial-read and expection, especially if your data can
be large, so that you can keep pending data in stream format, so consumers
that can take it this way are able to. If your data is mostly small, you can
read it using the length into a buffer and use your trial/error approach -
chances are derialzation will fail very quickly - although of course,
there's always a chance it will not fail at all - dangerous.

If you want to be more expressive, maybe you should go for a string (which
could even be XML someday) for the message identifier rather than an int --
for instance, you could send the name of a class to use to deserialize your
data on the other side, and use refection or a factory on the other side to
create the proper de-serializer instance. Versioning could be up to you in
your message preamble, or handled by each serialization protocol itself.

m

Also i am stuck on a scenario where i send data and cant proceed until i
get a response. One of my functions on the client fires a request but if
the client continues before getting a response it will crash. If i get it
to wait i end up poling and everything freezes for a second. I was
thinking of moving my interface logic and my actual application logic to 2
separate threads. Then i can make the app logic wait while the sent
message waits for a reply, meanwhile the interface thread continues and i
get no apparent freeze. But i am sure this is not good for performance or
is this ok?

thanks

[William Stacey [MVP]]

All the native types (i.e. string, int, etc) can be serialize and any type
that has [Serializable] attribute. That is pretty generic. If you just
want to send a string, then serialize the string and send it. So your
"contract" can be anything serializable can be sent as long as you have the
proper type and version on the server side. If you can't deserialize it,
then there is not much you could do with the type anyway except log it and
close the client connection. What do you plan to do with types you don't
have a type for? Just curious.

--
William Stacey [MVP]

"Daniel" <Da*****@vestryonline.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
| Hi
|
| i want to be able to check if information read that came from over a
socket
| is serilisable, if it isnt i want to handle it differently. Basically i am
| trying to make a generic receivedata function that i can send any form of
| data over the wire too and it will handle it appropriately.
|
| I know i could do a try catch on a serilisation exception but i dont think
| this is a good way to check as other things could cause such an error.
|
| I did think of writing into the first 4 bytes of the send stream an
| indenitifier for the response, then the slient can read those bytes and
| decide, but again it starts to become less generic. Ideally i would like
| anyone to send any info and i can handle it
|
| Any ideas?
|
| Also i am stuck on a scenario where i send data and cant proceed until i
get
| a response. One of my functions on the client fires a request but if the
| client continues before getting a response it will crash. If i get it to
| wait i end up poling and everything freezes for a second. I was thinking
of
| moving my interface logic and my actual application logic to 2 separate
| threads. Then i can make the app logic wait while the sent message waits
for
| a reply, meanwhile the interface thread continues and i get no apparent
| freeze. But i am sure this is not good for performance or is this ok?
|
| thanks
|
|