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\)]

Re: Socket connection

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" <nothing@null.v oid> wrote in message
news:OUFw5jLOGH A.2628@TK2MSFTN GP15.phx.gbl...[color=blue]
> 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.
>
>[/color]

[Sharon]

Re: Socket connection

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)" <me@home.com> wrote in message
news:AbednScpr_ aHtmPeRVn-uA@comcast.com. ..[color=blue]
> 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" <nothing@null.v oid> wrote in message
> news:OUFw5jLOGH A.2628@TK2MSFTN GP15.phx.gbl...[color=green]
>> 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.
>>
>>[/color]
>
>[/color]

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

Re: Socket connection

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" <nothing@null.v oid> wrote in message
news:uWAo%232MO GHA.3944@tk2msf tngp13.phx.gbl. ..[color=blue]
> 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)" <me@home.com> wrote in message
> news:AbednScpr_ aHtmPeRVn-uA@comcast.com. ..[color=green]
>> 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" <nothing@null.v oid> wrote in message
>> news:OUFw5jLOGH A.2628@TK2MSFTN GP15.phx.gbl...[color=darkred]
>>> 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.
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Sharon]

Re: Socket connection

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)" <me@home.com> wrote in message
news:AqKdnW74v8 Xi7mPeRVn-jg@comcast.com. ..[color=blue]
> 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" <nothing@null.v oid> wrote in message
> news:uWAo%232MO GHA.3944@tk2msf tngp13.phx.gbl. ..[color=green]
>> 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)" <me@home.com> wrote in message
>> news:AbednScpr_ aHtmPeRVn-uA@comcast.com. ..[color=darkred]
>>> 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" <nothing@null.v oid> wrote in message
>>> news:OUFw5jLOGH A.2628@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.
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[William Stacey [MVP]]

Re: Socket connection

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

--
William Stacey [MVP]

[William Stacey [MVP]]

Re: Socket connection

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