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.void> wrote in message
news:OU**************@TK2MSFTNGP15.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.