Test Availability of TCP Port?

[Guest]

Heya

Does anyone know if its possible to test the availability of a TCP port other than attempting to listen on a specific port and catching an exception

~~K

 

[Ed Kaim [MSFT]]

Although there's probably a better way, you could parse "netstat -anp tcp"
The secone column as "<host>:<port>" for the local machine.

Heya,

Does anyone know if its possible to test the availability of a TCP

port other than attempting to listen on a specific port and catching an
exception?

 

[Guest]

I was afraid of an answer like that :-

I think what I'll do is use a high port number (10,000+) and incrementally attempt to listen... somewhat of a hack, but oh well. I know in Java you can have it listen and hand you a port number that its listening on. This is an incredibly useful feature when building a server that supports lots of listening points.

 

[William Stacey]

You have your reasons, but what would be the point of that? Your clients
would still need to know what ports?

--
William Stacey, MVP

I was afraid of an answer like that

I think what I'll do is use a high port number (10,000+) and incrementally

attempt to listen... somewhat of a hack, but oh well. I know in Java you
can have it listen and hand you a port number that its listening on. This
is an incredibly useful feature when building a server that supports lots of
listening points.

 

[Ed Kaim [MSFT]]

I believe if you just use 0 as the port it'll find one available. You can
derive a class from TcpListener to expose the "Server" property in order to
get the local port, such as:

class MyServer : TcpListener

{

public MyServer() : base(new IPEndPoint(IPAddress.Any, 0)) {}

public int Port { get { return ((IPEndPoint)
this.Server.LocalEndPoint).Port; } }

}

I was afraid of an answer like that

I think what I'll do is use a high port number (10,000+) and incrementally

attempt to listen... somewhat of a hack, but oh well. I know in Java you
can have it listen and hand you a port number that its listening on. This
is an incredibly useful feature when building a server that supports lots of
listening points.

 

[Guest]

Ok, I'll give that a try. Right now what I am doing is attempting to listen on a port, catching the error (ErrorCode 10048, btw where the heck is the document that describes these TCP Errors?? I can't find it on MSDN), if an error is caught, it'll increment a static int and try again. It appears to work well for me, but catching an error and testing if its a certain error feels risky to me... its setting me up for an infinite loop

~~K

 

[Guest]

The point of it is basically in situations, like an FTP server that requires a seperate port for Data. It opens a random port and sends port number to the client

I have a similar scenario where I would like to accept a single socket connection and am using different port numbers as a means for identifying which connection goes with which object on my server, rather than having a single listening point and passing some sort of GUID to identify who should belong to the socket.

 

[Ed Kaim [MSFT]]

You may be better off just letting the OS assign a port for you, especially
if you have to send it to the client anyway (as in the way FTP works).

Yes, I agree the numeric error codes aren't very useful without an
explanation. If you use Visual Studio, it comes with a little tool called
"Visual C++ Error Lookup" that does conversions of the error code to a
string. 10048 means "Only one usage of each socket address (protocol/network
address/port) is normally permitted." You can access the tool from Start |
All Programs | Microsoft Visual Studio .NET [2003] | Visual Studio .NET
Tools.

Ok, I'll give that a try. Right now what I am doing is attempting to

listen on a port, catching the error (ErrorCode 10048, btw where the heck is
the document that describes these TCP Errors?? I can't find it on MSDN), if
an error is caught, it'll increment a static int and try again. It appears
to work well for me, but catching an error and testing if its a certain
error feels risky to me... its setting me up for an infinite loop.

 

[William Stacey]

I have a similar scenario where I would like to accept a single socket
connection and am using different port >numbers as a means for identifying
which connection goes with which object on my server

I would not use ports for that. Ports are a valuable and limited resource.
So you have 100 clients connecting, and each gets a different port? Not a
good idea IMHO. Sockets are made for that. A socket is unique with four
pieces (src ip, src port, dst ip, dst port). When a client connects, you
can handle the new socket in another thread or async - each client will have
a unique socket. If using udp, then probably want some kind of ticket or
key as you said. This port approach will also make firewall people turn
green and makes deployment very knotty and limits your reach.

 

[Jon Skeet [C# MVP]]

connection and am using different port >numbers as a means for identifying
which connection goes with which object on my server

I would not use ports for that. Ports are a valuable and limited resource.
So you have 100 clients connecting, and each gets a different port? Not a
good idea IMHO.

Ports aren't *that* limited. There are 64K of them - more than enough
for 100 clients to each have their own port, even if you're running 100
such programs.

Sockets are made for that. A socket is unique with four
pieces (src ip, src port, dst ip, dst port). When a client connects, you
can handle the new socket in another thread or async - each client will have
a unique socket. If using udp, then probably want some kind of ticket or
key as you said. This port approach will also make firewall people turn
green and makes deployment very knotty and limits your reach.

Certainly the firewall issue is a pain. I don't think it's *always* a
bad idea to grab an extra port though. Sockets only simply allow a
single stream of information back and forward - when multiple
simultaneous streams are required, you either have to design your
protocol around that, or use more than one port.

 

[DalePres]

Like Jon said, ports aren't limited, in fact sockets have ports as
properties so port count isn't the reason for not using ports to identify
clients. The more sure way to identify which client is which is by the
TcpClient or by the associated NetworkStream.

In my multi-user client/server apps, I create a new class which has the
TcpClient and/or NetworkStream as a property or, if more appropriate in the
application, I have inherited from TcpClient instead. Then create a
collection of this class, adding one member for each client connection. You
may want to add custom indexers for easy searching the collection. Then you
just send any data to the appropriate object. Received data could be
handled within the object as well, so keeping what piece of data goes with
which client becomes seamless.

Dale

 

[William Stacey]

Ports aren't *that* limited. There are 64K of them - more than enough

for 100 clients to each have their own port, even if you're running 100
such programs.

They still are limited. You also have the problem of finding a free port to
listen on dynamically. This is not, however, needed to address the problem
I think he is asking about. No self respecting server program I have seen
uses ports in that manner (not even ftp). I am sure they exist, but they
are not self respecting ;-)

Sockets only simply allow a
single stream of information back and forward - when multiple
simultaneous streams are required, you either have to design your
protocol around that, or use more than one port.

Huh? You can listen and create new socket when client connects. Will be
unique to that client. If you choose to use a thread for each client, a
thread pool, or async the server is another matter. Did I miss your
intention?

 

[William Stacey]

I was not refering to ephemeral ports like a client would use to
connect/send. I was referring to server *listening on multiple ports. You
don't need to do that unless your offering different service at each port
(i.e. control port, data port, e.g. ftp) Your suggesting he listen on many
ports?

--
William Stacey, MVP

Like Jon said, ports aren't limited, in fact sockets have ports as
properties so port count isn't the reason for not using ports to identify
clients. The more sure way to identify which client is which is by the
TcpClient or by the associated NetworkStream.

In my multi-user client/server apps, I create a new class which has the
TcpClient and/or NetworkStream as a property or, if more appropriate in the
application, I have inherited from TcpClient instead. Then create a
collection of this class, adding one member for each client connection. You
may want to add custom indexers for easy searching the collection. Then you
just send any data to the appropriate object. Received data could be
handled within the object as well, so keeping what piece of data goes with
which client becomes seamless.

Dale

 

[Jon Skeet [C# MVP]]

They still are limited.

Yes, but not so limited that you need to make absolutely sure that you
don't have more than one per client.

You also have the problem of finding a free port to
listen on dynamically.

And that's easy, by specifying 0 as the port, as has already been
pointed out.

This is not, however, needed to address the problem
I think he is asking about. No self respecting server program I have seen
uses ports in that manner (not even ftp). I am sure they exist, but they
are not self respecting ;-)

I think blanket statements like that (even with smileys) are a bad
idea, IMO.

Huh? You can listen and create new socket when client connects. Will be
unique to that client. If you choose to use a thread for each client, a
thread pool, or async the server is another matter. Did I miss your
intention?

Who's to say you'll want the same protocol on every port? You may well
want to have a "control" port which has one protocol (and is fixed) and
then potentially several "data" ports which are dynamically allocated.
That may well lead to a much simpler protocol in some situations.

 

[William Stacey]

And that's easy, by specifying 0 as the port, as has already been

pointed out.

Yes, we know the system can assign ephemeral ports using 0 for port number.
But again, we are talking about a server app. So I still have the same
question - why when you can use the connection socket to identify the
client?

I think blanket statements like that (even with smileys) are a bad
idea, IMO.

? I can't think of a mainstream server that does that besides maybe ftp
server that does something close. And ftp has firewall issues for this
reason. Do you know of one? I have also never seen such a method used as
an example in any of my socket or networking books (and have many) . I
never said you can't do it, but again, but only that is not the best
solution to his question from what I see in the text. Especially as a
simple solution exists without resorting to having clients connect to a
seperate port and send back client back a dynamic port in a message and then
the client connects back using that port - uggg..

Who's to say you'll want the same protocol on every port? You may well
want to have a "control" port which has one protocol (and is fixed) and
then potentially several "data" ports which are dynamically allocated.

Who says you can't use both udp and tcp on the same port? You can listen on
one port and service as many unique client/port pairs as the system will
allow. I am not talking about a server with a few ports open for specific
services (i.e. w2k, ad, etc). That is fine and normal. The OP wants a
seperate port on the server for each client that connects AFAICT. All I am
saying is there is no need for that using sockets, unless I miss his point.

 

[DalePres]

Not at all.. I don't think that it is practical at all to listen on multiple
ports. The socket or TcpListener will listen on one port. You said ports
are limited. For all practical purposes, they are not. You would run out
of memory creating sockets long before you ran out of ports.

All I'm saying is that tracking the port is not the method by which he
should track clients or connections. The stream object, or the parent
TcpClient or Socket is the way to manage connections. Hmmmm.. isn't that
what you said? Only differently? So no need to flame; I'm basically
agreeing with you except on the one point that ports are limited. <Smile>

Dale

I was not refering to ephemeral ports like a client would use to
connect/send. I was referring to server *listening on multiple ports. You
don't need to do that unless your offering different service at each port
(i.e. control port, data port, e.g. ftp) Your suggesting he listen on many
ports?

--
William Stacey, MVP

Like Jon said, ports aren't limited, in fact sockets have ports as
properties so port count isn't the reason for not using ports to identify
clients. The more sure way to identify which client is which is by the
TcpClient or by the associated NetworkStream.

In my multi-user client/server apps, I create a new class which has the
TcpClient and/or NetworkStream as a property or, if more appropriate in the
application, I have inherited from TcpClient instead. Then create a
collection of this class, adding one member for each client connection. You
may want to add custom indexers for easy searching the collection. Then you
just send any data to the appropriate object. Received data could be
handled within the object as well, so keeping what piece of data goes with
which client becomes seamless.

Dale

Not

 

[Jon Skeet [C# MVP]]

Yes, we know the system can assign ephemeral ports using 0 for port number.
But again, we are talking about a server app. So I still have the same
question - why when you can use the connection socket to identify the
client?

And I still have the same response - to have multiple connections which
don't require the same protocol.

? I can't think of a mainstream server that does that besides maybe ftp
server that does something close.

Neither can I. That doesn't mean your generalisation is correct though.

And ftp has firewall issues for this reason.

Indeed - and if a firewall might be involved, it's clearly a bad idea.
However, that's not always the case.

Who says you can't use both udp and tcp on the same port? You can listen on
one port and service as many unique client/port pairs as the system will
allow.

I don't see where UDP comes in here. A single port should only service
a single protocol. What you can do is have two ports, one for one
protocol and one for another, of course. That would be a better answer
to my suggested "problem". However, here's another scenario:

You have an app which you don't want to allocate a fixed port number
for (as fixed port numbers are limited, so there may be clashes).
However, you want to communicate in a simple stream-based fashion, e.g.
with other instances of the same app running on the same box. You could
use some other IPC mechanism to share the port number, but that IPC
mechanism may not be nearly as well suited to the rest of the data
streaming as simple networking (which may already be part of the app
for other reasons). Dynamically creating a port and then sharing the
number creates a simple clash-free stream.

I am not talking about a server with a few ports open for specific
services (i.e. w2k, ad, etc). That is fine and normal. The OP wants a
seperate port on the server for each client that connects AFAICT. All I am
saying is there is no need for that using sockets, unless I miss his point.

And I'm saying that while there *may* not be a need, saying that
dynamically allocated port numbers is *never* needed (or at least
advantageous) is being short-sighted.

 

[ozbear]

They still are limited. You also have the problem of finding a free port to
listen on dynamically.

One always "listens" on the -same- port. When the connection is to be
accepted, a new ephemeral port (look it up) is used to actually
carry the traffic.

Oz

 

[Jon Skeet [C# MVP]]

One always "listens" on the -same- port. When the connection is to be
accepted, a new ephemeral port (look it up) is used to actually
carry the traffic.

That's not actually what the OP was after though - he was after
listening on a dynamically allocated port.

 

[William Stacey [MVP]]

One always "listens" on the -same- port. When the connection is to be

accepted, a new ephemeral port (look it up) is used to actually
carry the traffic.

You said it with authority. However that is not correct. If you listen on
55, you send on 55. Unless you explicitly sent reply on another port.