Basic questions

  • Thread starter Thread starter Denville Longhurst
  • Start date Start date
D

Denville Longhurst

Hello experts

I am sure the answer is in the paperwork somewhere, but the following have
evaded me:

1. Can I set the time-out for attempting to make a TCP/IP connection? At
the moment it seems to take about 20 seconds before returning failure. It's
a small, totally private, network with no routing etc. so I would like to
set the timeout at 1 or 2 seconds.

2. When sending to a TCP/IP address not on the PC's local sub-net but on the
same (small) physical network, can I somehow tell the system to look for it
locally without setting a route in the routing table? (Or if not, can I set
a route within the app with an API call?)

3. I want to make infrequent connections (maybe once a minute) to the server
then disconnect so that other PCs can do the same. I couldn't find a
'disconnect' command so should I (and is it safe to) destroy the socket each
time and re-create it anew the next?

There are no third-party applications involved, both clients and server will
be writen by me.

OS is W2K or XP Pro

Many thanks for any advice..

Denville
 
Denville Longhurst said:
Hello experts

I am sure the answer is in the paperwork somewhere, but the following have
evaded me:

1. Can I set the time-out for attempting to make a TCP/IP connection? At
the moment it seems to take about 20 seconds before returning failure. It's
a small, totally private, network with no routing etc. so I would like to
set the timeout at 1 or 2 seconds.
Click to expand...

There are settings for such things but it isn't
ONE setting TCP vs. application specific
settings for UDP (UPD doesn't have the concept
of waiting on it's own.)

Don't mess with such things in 99.999% of the
cases.
2. When sending to a TCP/IP address not on the PC's local sub-net but on the
same (small) physical network, can I somehow tell the system to look for it
locally without setting a route in the routing table? (Or if not, can I set
a route within the app with an API call?)
Click to expand...

Yes, but it DOES involve "setting routers" although
that is usually trivial. Setting a DEFAULT GATEWAY
modifies the routing table to send ALL non-local traffic
to a particular gateway (i.e., router).

If you have MULTIPLE routers to different networks
and wish to specify WHICH to use you must add additional
routers to the stations (that have this choice.)
3. I want to make infrequent connections (maybe once a minute) to the server
then disconnect so that other PCs can do the same. I couldn't find a
'disconnect' command so should I (and is it safe to) destroy the socket each
time and re-create it anew the next?
Click to expand...

Programmatically? There are ways to disconnect
(TCP) for instance -- just abanding it is a poor practice
and likely won't case server problems if done occasionally
but a program that did this many times with cease might
use up a lot of system resources.
There are no third-party applications involved, both clients and server will
be writen by me.
Click to expand...

Have you ever programmed IP before?

Do you know the different between UDP
and TCP? (From your description above
I would suggest you look strongly at UDP
and avoid the overhead of the TCP setup
and tear down.)

Although you are welcome to ask this here,
you might benefit for (limited) crossposting
or just posting to one of the network programming
groups -- IP is pretty much IP whether it is MS
or not.
OS is W2K or XP Pro

Many thanks for any advice..
Click to expand...

What are you REALLY trying to do?
(Not how you think you WANT to do it.)
 
I need to send bits of information to a server which then decides what to do
with them (eg send the information to a remote site over a serial port). I
have done this successfully for the last six or so years using UDP
broadcasts (to a specific port) and it has worked flawlessly. Two things
have changed recently, specifically the data can occasionally exceed the
maximum datagram size allowed for a single UDP packet, and I have been asked
to demonstrate that delivery is 'guaranteed' in the sense that the UDP
packet has not got 'lost'. Even the latter has been relatively easy to
achieve, by getting an acknowledgement back from the server. However the
big problem is when the data has to be split between two datagrams, and
there is the demonstrable if remote possibility that packets broadcast
simultaneously by two client PCs to the server will get mixed up. I find
myself having to re-invent something that is already built in to TCP rather
than UDP. I have experimented with TCP but the problems are:

1. If the server happens to be down, it can take the client app 20 or 25
seconds to time out of the attempt to make the connection. If it is an
attended PC the user thinks that the application has hung. If I do it
assynchronously, the user has left the PC before failure is notified. Since
it is a small and private network, I would think that connection is either
established or not almost immediately, and a second or two timeout would
solve this problem.

2. The server is currently a PC but I am moving to a small programmable
serial/ethernet device which I would like to deploy without specific
configuration (ie with a pre-set IP address which is known but not
necessarily within the local sub-net). (I already have this running under
UDP.) If I change to TCP, I would like the application to be able to
connect to this device without requiring manual configuration of the PC's
routing table. At the moment I have to enter a route manually using the
ROUTE command (unsurprisingly) but I cannot guarantee the end-user's skill
and the app must install and configure completely automatically.

3. My preference for opening and closing a TCP connection is based on
wanting to have a server with a small client capability but which is used
over time by a larger number of clients on the basis that each communication
will open the TCP connection, squirt the data, then close it for someone
else to use.

Many thanks for the interest so far, feel free to ignore all this, but since
you asked, the above just about sums it up. As you can see, I have become
fairly expert at UDP over the years, but TCP is just that bit more complex.

Denville.
 
Back
Top