I need to write a client application that polls a smart device for its
data on a regular basis. The device only accepts one TCP connection at
a time on a single port. The device is a peice of hardware that just
returns its data when it receives a request. I have no control over the
design of the device.

I want to allow multiple clients to connect to a device.  However,
since the device only accepts one connection on a single port, I have a
few problems. Basically, the two options that I see are:

1. Create a proxy application that maintains a persistent connection to
the device and accepts multiple connections from the client
application. I would prefer to avoid this if possible to reduce the
complexity for the end user.

2. Open and close a connection with each request. Hopefully the number
of clients won't get too large to the point where connection requests
timeout. Just FYI...the data is relatively small and the most a single
client will request data is once a second.

Which method is my best bet? I am thinking for a small number of
clients, option 2 will be sufficient. What is the overhead of opening
and closing a connection for each request if the data packet is small?
If the clients request data at most once a second, at what point will I
have to worry about having too many connections? FYI...The client and
the device will be on the same local network.

Any advice is appreciated. Thanks!

yof***@comcast.net wrote in news:1143819832.151272.41930
@z34g2000cwc.googlegroups.com:

FWIW, I have implemented option 1 (a single connection proxy) for several
other projects and it has worked quite well for me.  Option 2 is only
viable when you can *guarantee* that there will *never* be more clients. 
Rule #7b of the "Hitchhiker's Guide to Client/Server Design" says that you
will always end up with more clients than you expected. 

-mdb

I totally agree. I am curious though about where the cutoffs are? Are
we talking 10 clients will be too much, or hundreds?

At a lower level, here is what I want to know. What is the overhead of
opening and closing a connection with each request? Is this feasible
with 10 different clients requesting data once a second. If so, then I
am happy. When more than 10 clients are required, we can simple charge
more money for option 1.  :)

yof***@comcast.net wrote in news:1143823807.215423.38480
@e56g2000cwe.googlegroups.com:

Much of what you are asking will depend on the device you are connecting
to, the type of connection it has, what kind of processing is being done on
the device in order to return the data, etc.  I can't really guage that -
you will probably have to do some tests to determine this.  If this was a
server-class network appliance I would say 10 requests per second is no
problem.  But if I remember you are talking to a 'Smart Device' which could
be anything, running on a slow processor with a bad network stack.  My
guess would be that 10 connections per second might be pushing it for a
device of this type, again depending on how much data is being returned and
what kind of processing has to be done to generate that data.

Bottom line is that you will have to test to find out where the limit is
for your particular application.

-mdb

Binary representation of a double?
Possible bug with SerialPort Parity.None and/or ParityReplace
not able to read an XSD file
From VB.NET to Word 2003
WebRequest and Range Header