Socket connection

[Sharon]

Hi all.
I'm trying first time async socket connection.
In all the examples i've seen, the server connection is closed
when the message is complete.
Is it common to close the connection after every message?
Also, the message is complete, meaning there is no more data to read, only
when the client closes the connection.
My solution is to keep the connection open, and send a terminator / eof
at the end of every message.
Is it the right solution?
Thanks,
Sharon.

[C.C. \(aka Me\)]

There are a few things to think about when working with sockets and your own
protocol (ie. the messages that are sent and received.)

1. What is the message format? In other words how is the data encoded that
is being sent. Maybe it is an XML format or HTTP request, or maybe it is
some binary block of data similar to what a game would use.

2. Is there a way to determine the size of a packet or the end of it? If it
is a binary block of data maybe the first 2 bytes represent the size/length
of the packet, if it is HTTP then a CR+LF+CR+LF can signify the end of it or
a Content-Length header.

3. Is there always going to be a reply to every request? Will you ever send
something and not expect/require a reply.

4. Do you want to support persistant connections on your servers side? This
can either increase or decrease the load on your server depending on how
your system works. If you are goin to make a bunch of requests and then none
for a while then you probably want to use a persistant connection for all
the requests and then close it. If you will make one request every few
minutes then maybe you should not use persistant connections at all. This
is all up to you and how you want to implement it but keep in mind that no
matter what there will be more logic/code involved in using persistant
connections then not using them (what if the connection gets closed and you
dont expect it, can both server and client close the connection, etc.)

5. Are you going to be communicating with systems that use different
programming languages? This is just something to keep in your mind when
deciding on the protocol you will use. Something like XML is non-language
specific while something like a binary structure is usually language
specific.

Now.. To answer your question a bit more in case the above didnt help you
out. Ready for it.. here it comes...

It is up to you how your system will work in terms of opening, closing and
retaining a connection!

That is the overall answer I was getting at I guess.. It is up to you and
the system you are designing (server, clients, etc). Here are some
rule-of-thumb's that may help out though.

1. Where do persistant connections work better?
- Systems that require a login or keep track of a transaction. Each
connection is a "user" that is logged in and on the server it is handled by
a separate thread.

- If a client will make several requests in a short period of time. Like a
web browser or database client.

- If there is some load intense process with every new connection. Maybe
for every new connection the users IP address is checked against some
backend system and then some processing is performed.

- Will connection be able to communicate with each other like a chat
program? Maybe each connection is a user and they will talk with each other
via text messages.

2. Where do non-persistant connection work better?
- A server that is used to query data and does not know about the "user"
connected to it. This type of server generally handles a single request
(query) and provides the answer to the client. There is no notion of a
session or user in this setup.

- If a client only makes 1 request every few minutes. My waste server
resources for a client that only talks once in a while?
That about covers what I am trying to get at. I hope that this gives you
some help in some way. If not then let me know!
--
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

"Sharon" <no*****@null.v oid> wrote in message
news:OU******** ******@TK2MSFTN GP15.phx.gbl...

Hi all.
I'm trying first time async socket connection.
In all the examples i've seen, the server connection is closed
when the message is complete.
Is it common to close the connection after every message?
Also, the message is complete, meaning there is no more data to read, only
when the client closes the connection.
My solution is to keep the connection open, and send a terminator / eof
at the end of every message.
Is it the right solution?
Thanks,
Sharon.

[Sharon]

Hi Charles.
Thanks a bunch for your detailed reply.
Some details about the app:
1. the server will send a message at least every few seconds.
2. message format is XML.
3. each connection is a logged user .
4. users will be able to chat through the server.

So i guess i'll need to append eof to every message and use persistent
connection.
My problem now, is persistent connections management.
I'm thinking about a time interval maintenance routine.
When a disconnected worker socket is detected, should it wait another round
for
the socket to reconnect, before removing it from the worker sockets list?
Sharon.

"C.C. (aka Me)" <[e-mail]> wrote in message
news:Ab******** ************@co mcast.com...

There are a few things to think about when working with sockets and your
own protocol (ie. the messages that are sent and received.)

1. What is the message format? In other words how is the data encoded that
is being sent. Maybe it is an XML format or HTTP request, or maybe it is
some binary block of data similar to what a game would use.

2. Is there a way to determine the size of a packet or the end of it? If
it is a binary block of data maybe the first 2 bytes represent the
size/length of the packet, if it is HTTP then a CR+LF+CR+LF can signify
the end of it or a Content-Length header.

3. Is there always going to be a reply to every request? Will you ever
send something and not expect/require a reply.

4. Do you want to support persistant connections on your servers side?
This can either increase or decrease the load on your server depending on
how your system works. If you are goin to make a bunch of requests and
then none for a while then you probably want to use a persistant
connection for all the requests and then close it. If you will make one
request every few minutes then maybe you should not use persistant
connections at all. This is all up to you and how you want to implement
it but keep in mind that no matter what there will be more logic/code
involved in using persistant connections then not using them (what if the
connection gets closed and you dont expect it, can both server and client
close the connection, etc.)

5. Are you going to be communicating with systems that use different
programming languages? This is just something to keep in your mind when
deciding on the protocol you will use. Something like XML is non-language
specific while something like a binary structure is usually language
specific.

Now.. To answer your question a bit more in case the above didnt help you
out. Ready for it.. here it comes...

It is up to you how your system will work in terms of opening, closing and
retaining a connection!

That is the overall answer I was getting at I guess.. It is up to you and
the system you are designing (server, clients, etc). Here are some
rule-of-thumb's that may help out though.

1. Where do persistant connections work better?
- Systems that require a login or keep track of a transaction. Each
connection is a "user" that is logged in and on the server it is handled
by a separate thread.

- If a client will make several requests in a short period of time. Like
a web browser or database client.

- If there is some load intense process with every new connection. Maybe
for every new connection the users IP address is checked against some
backend system and then some processing is performed.

- Will connection be able to communicate with each other like a chat
program? Maybe each connection is a user and they will talk with each
other via text messages.

2. Where do non-persistant connection work better?
- A server that is used to query data and does not know about the "user"
connected to it. This type of server generally handles a single request
(query) and provides the answer to the client. There is no notion of a
session or user in this setup.

- If a client only makes 1 request every few minutes. My waste server
resources for a client that only talks once in a while?
That about covers what I am trying to get at. I hope that this gives you
some help in some way. If not then let me know!
--
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

"Sharon" <no*****@null.v oid> wrote in message
news:OU******** ******@TK2MSFTN GP15.phx.gbl...

Hi all.
I'm trying first time async socket connection.
In all the examples i've seen, the server connection is closed
when the message is complete.
Is it common to close the connection after every message?
Also, the message is complete, meaning there is no more data to read,
only
when the client closes the connection.
My solution is to keep the connection open, and send a terminator / eof
at the end of every message.
Is it the right solution?
Thanks,
Sharon.

[C.C. \(aka Me\)]

Sharon,

Glad the info helped.

One thing that I have seen done in multi-threaded communication applications
is the implementation of a "vulture". This is a separate thread that is
sleeping most of the time but when it is not then it goes through the list
of all of the current connections and determines if they should be removed
or not. It will do this by looking to see if the connection is still open
(at the socket level) and maybe how much time has passed since the last
request was made from the client - maybe it will close/remove any
connections after 10 minutes of inactivity. This is similar to what you
mentioned in terms of a time interval maintance routine.

It sounds as though you will need persistant connections since there will be
chatting between the users. Also since you are using some sort of login
method (each connection is a logged user you said) it will make it easier
because the actual socket connection can be used to identify the user
instead of having to pass a "key" with every request to the server.

Lastly, you mentioned waiting for a reconnect to occur when a connection is
lost. This is a good idea but it could be hard to implement in a
correct/good way. Depending on your requirements you may want to hold off
implementing it in the beginning and see if you really need it. To
determine if you really need this type of behavior you may want to look at
how often a connection is actually dropped (aka. lost connection) and what
benifit you will receive from implementing it - is it really that big of a
deal to just create a new worker thread and perform the login again? Is
there a lot of "session" type of information that gets created that could
benifit from a "continue where you left off" feature because that is what we
are talking about really.

Hope this helps!

--
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

"Sharon" <no*****@null.v oid> wrote in message
news:uW******** ********@tk2msf tngp13.phx.gbl. ..

Hi Charles.
Thanks a bunch for your detailed reply.
Some details about the app:
1. the server will send a message at least every few seconds.
2. message format is XML.
3. each connection is a logged user .
4. users will be able to chat through the server.

So i guess i'll need to append eof to every message and use persistent
connection.
My problem now, is persistent connections management.
I'm thinking about a time interval maintenance routine.
When a disconnected worker socket is detected, should it wait another
round for
the socket to reconnect, before removing it from the worker sockets list?
Sharon.

"C.C. (aka Me)" <[e-mail]> wrote in message
news:Ab******** ************@co mcast.com...

There are a few things to think about when working with sockets and your
own protocol (ie. the messages that are sent and received.)

1. What is the message format? In other words how is the data encoded
that is being sent. Maybe it is an XML format or HTTP request, or maybe
it is some binary block of data similar to what a game would use.

2. Is there a way to determine the size of a packet or the end of it? If
it is a binary block of data maybe the first 2 bytes represent the
size/length of the packet, if it is HTTP then a CR+LF+CR+LF can signify
the end of it or a Content-Length header.

3. Is there always going to be a reply to every request? Will you ever
send something and not expect/require a reply.

4. Do you want to support persistant connections on your servers side?
This can either increase or decrease the load on your server depending on
how your system works. If you are goin to make a bunch of requests and
then none for a while then you probably want to use a persistant
connection for all the requests and then close it. If you will make one
request every few minutes then maybe you should not use persistant
connections at all. This is all up to you and how you want to implement
it but keep in mind that no matter what there will be more logic/code
involved in using persistant connections then not using them (what if the
connection gets closed and you dont expect it, can both server and client
close the connection, etc.)

5. Are you going to be communicating with systems that use different
programming languages? This is just something to keep in your mind when
deciding on the protocol you will use. Something like XML is non-language
specific while something like a binary structure is usually language
specific.

Now.. To answer your question a bit more in case the above didnt help you
out. Ready for it.. here it comes...

It is up to you how your system will work in terms of opening, closing
and retaining a connection!

That is the overall answer I was getting at I guess.. It is up to you and
the system you are designing (server, clients, etc). Here are some
rule-of-thumb's that may help out though.

1. Where do persistant connections work better?
- Systems that require a login or keep track of a transaction. Each
connection is a "user" that is logged in and on the server it is handled
by a separate thread.

- If a client will make several requests in a short period of time. Like
a web browser or database client.

- If there is some load intense process with every new connection. Maybe
for every new connection the users IP address is checked against some
backend system and then some processing is performed.

- Will connection be able to communicate with each other like a chat
program? Maybe each connection is a user and they will talk with each
other via text messages.

2. Where do non-persistant connection work better?
- A server that is used to query data and does not know about the "user"
connected to it. This type of server generally handles a single request
(query) and provides the answer to the client. There is no notion of a
session or user in this setup.

- If a client only makes 1 request every few minutes. My waste server
resources for a client that only talks once in a while?
That about covers what I am trying to get at. I hope that this gives you
some help in some way. If not then let me know!
--
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

"Sharon" <no*****@null.v oid> wrote in message
news:OU******** ******@TK2MSFTN GP15.phx.gbl...

Hi all.
I'm trying first time async socket connection.
In all the examples i've seen, the server connection is closed
when the message is complete.
Is it common to close the connection after every message?
Also, the message is complete, meaning there is no more data to read,
only
when the client closes the connection.
My solution is to keep the connection open, and send a terminator / eof
at the end of every message.
Is it the right solution?
Thanks,
Sharon.

[Sharon]

Hi,
I already implemented a session mechanism, so i'll keep it, to let users
regain session when reconnecting, if the session hasn't timed out yet.
So now the only thing i have to do, is to implement a vulture, shouldn't be
too hard.
I really appreciate your guidance, thanks,
Sharon.

"C.C. (aka Me)" <[e-mail]> wrote in message
news:Aq******** ************@co mcast.com...

Sharon,

Glad the info helped.

One thing that I have seen done in multi-threaded communication
applications is the implementation of a "vulture". This is a separate
thread that is sleeping most of the time but when it is not then it goes
through the list of all of the current connections and determines if they
should be removed or not. It will do this by looking to see if the
connection is still open (at the socket level) and maybe how much time has
passed since the last request was made from the client - maybe it will
close/remove any connections after 10 minutes of inactivity. This is
similar to what you mentioned in terms of a time interval maintance
routine.

It sounds as though you will need persistant connections since there will
be chatting between the users. Also since you are using some sort of
login method (each connection is a logged user you said) it will make it
easier because the actual socket connection can be used to identify the
user instead of having to pass a "key" with every request to the server.

Lastly, you mentioned waiting for a reconnect to occur when a connection
is lost. This is a good idea but it could be hard to implement in a
correct/good way. Depending on your requirements you may want to hold off
implementing it in the beginning and see if you really need it. To
determine if you really need this type of behavior you may want to look at
how often a connection is actually dropped (aka. lost connection) and what
benifit you will receive from implementing it - is it really that big of a
deal to just create a new worker thread and perform the login again? Is
there a lot of "session" type of information that gets created that could
benifit from a "continue where you left off" feature because that is what
we are talking about really.

Hope this helps!

--
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

"Sharon" <no*****@null.v oid> wrote in message
news:uW******** ********@tk2msf tngp13.phx.gbl. ..

Hi Charles.
Thanks a bunch for your detailed reply.
Some details about the app:
1. the server will send a message at least every few seconds.
2. message format is XML.
3. each connection is a logged user .
4. users will be able to chat through the server.

So i guess i'll need to append eof to every message and use persistent
connection.
My problem now, is persistent connections management.
I'm thinking about a time interval maintenance routine.
When a disconnected worker socket is detected, should it wait another
round for
the socket to reconnect, before removing it from the worker sockets list?
Sharon.

"C.C. (aka Me)" <[e-mail]> wrote in message
news:Ab******** ************@co mcast.com...

There are a few things to think about when working with sockets and your
own protocol (ie. the messages that are sent and received.)

1. What is the message format? In other words how is the data encoded
that is being sent. Maybe it is an XML format or HTTP request, or maybe
it is some binary block of data similar to what a game would use.

2. Is there a way to determine the size of a packet or the end of it? If
it is a binary block of data maybe the first 2 bytes represent the
size/length of the packet, if it is HTTP then a CR+LF+CR+LF can signify
the end of it or a Content-Length header.

3. Is there always going to be a reply to every request? Will you ever
send something and not expect/require a reply.

4. Do you want to support persistant connections on your servers side?
This can either increase or decrease the load on your server depending
on how your system works. If you are goin to make a bunch of requests
and then none for a while then you probably want to use a persistant
connection for all the requests and then close it. If you will make one
request every few minutes then maybe you should not use persistant
connections at all. This is all up to you and how you want to implement
it but keep in mind that no matter what there will be more logic/code
involved in using persistant connections then not using them (what if
the connection gets closed and you dont expect it, can both server and
client close the connection, etc.)

5. Are you going to be communicating with systems that use different
programming languages? This is just something to keep in your mind when
deciding on the protocol you will use. Something like XML is
non-language specific while something like a binary structure is usually
language specific.

Now.. To answer your question a bit more in case the above didnt help
you out. Ready for it.. here it comes...

It is up to you how your system will work in terms of opening, closing
and retaining a connection!

That is the overall answer I was getting at I guess.. It is up to you
and the system you are designing (server, clients, etc). Here are some
rule-of-thumb's that may help out though.

1. Where do persistant connections work better?
- Systems that require a login or keep track of a transaction. Each
connection is a "user" that is logged in and on the server it is handled
by a separate thread.

- If a client will make several requests in a short period of time.
Like a web browser or database client.

- If there is some load intense process with every new connection.
Maybe for every new connection the users IP address is checked against
some backend system and then some processing is performed.

- Will connection be able to communicate with each other like a chat
program? Maybe each connection is a user and they will talk with each
other via text messages.

2. Where do non-persistant connection work better?
- A server that is used to query data and does not know about the "user"
connected to it. This type of server generally handles a single request
(query) and provides the answer to the client. There is no notion of a
session or user in this setup.

- If a client only makes 1 request every few minutes. My waste server
resources for a client that only talks once in a while?
That about covers what I am trying to get at. I hope that this gives you
some help in some way. If not then let me know!
--
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

"Sharon" <no*****@null.v oid> wrote in message
news:OU******** ******@TK2MSFTN GP15.phx.gbl...
Hi all.
I'm trying first time async socket connection.
In all the examples i've seen, the server connection is closed
when the message is complete.
Is it common to close the connection after every message?
Also, the message is complete, meaning there is no more data to read,
only
when the client closes the connection.
My solution is to keep the connection open, and send a terminator / eof
at the end of every message.
Is it the right solution?
Thanks,
Sharon.

[William Stacey [MVP]]

No need to spin another thread, just do it in the listen loop when Now >
NextCollectTime .

--
William Stacey [MVP]

[William Stacey [MVP]]

| For async ones: in callback method thread can wait for specific timeout on
IAsyncResult.Wa itHandle.

But that means you still need a thread blocking on Wait for some timeout
which would negate the async benefit. So you would need a thread blocking on
Wait for each socket or would need a thread pooling after some timeout.