Test Availability of TCP Port?

[William Stacey [MVP]]

And I still have the same response - to have multiple connections which

don't require the same protocol.

I assume by protocol, you are talking about network protocols like udp/tcp?
No?
You can do this with one port. If your talking application level protocols,
you can still do it on one port. Assuming you have some kind of message
format and not just streaming. If we are talking upd, this is really easy.

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

It's not a generalisation like that "is good, that bad". It's question of
how to properly and efficiently design a server. It's like someone saying
they will design their server with 1000 threads so 1000 clients can connect.
Someone who said that, would need some comments as to why that is probably
not a good idea. Sure you "can" do it, if you want to be literal. The
reasons stated from the OP are no reason to use multiple ports/listeners on
a server.

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

And we agree. Heh.

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:

As we are talking sockets and ports, I assumed we by protocols, you mean
udp/tcp.
"single port should only service a single protocol"?? Don't tell DNS that
has been listening for UDP and TCP on port 53 for 20+ years. A quick review
of the services file will show you some of the services that listen for udp
and tcp on the port.

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

Gee. Isn't that what I have been saying. You said ports are not limited,
now they are?

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.

Agreed. This would be akin to sharing a mutex name or some other kernel
sync object. Somehow the other process must know what to connect to. So
you can "fix" it upfront or do it dynamically, share the info via the reg,
etc. No problems here.

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.

My point was actually a very simple one meant to the help the OP. Via his
post, it seemed to me that he *thought, the only way you could have multiple
clients is to have multiple ports. This obviously is wrong and not needed
for stated for purpose (unless the purpose is not stated fully.) I never
said I could never think of a situation where it could be useful, nor did
anyone ask. I never say never (at least I try not to). I think we are
probably done with this. Cheers

 

[Guest]

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

Thats exactly what I am doing this this case..

 

[Guest]

This is where I point out that windows filesharing follows (or at least used to!) this model..

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

 

[William Stacey [MVP]]

You are obviously free to do what you like. As an fyi, you can fix one data
port and service "n" number of clients if want. My question is how is it
better for your app to use multiple data ports for this?

 

[Jon Skeet [C# MVP]]

I assume by protocol, you are talking about network protocols like udp/tcp?

No. I'm talking protocol such as NNTP, SMTP etc - except probably one
specifically for your application.

No?
You can do this with one port. If your talking application level protocols,
you can still do it on one port. Assuming you have some kind of message
format and not just streaming. If we are talking upd, this is really easy.

You *can* do it, but you have to either have one protocol which
supports all the different kinds of things you want to do, or one
protocol which just says which protocol you want to "switch" to -
either way, it's a bit messy.

It's not a generalisation like that "is good, that bad". It's question of
how to properly and efficiently design a server. It's like someone saying
they will design their server with 1000 threads so 1000 clients can connect.
Someone who said that, would need some comments as to why that is probably
not a good idea. Sure you "can" do it, if you want to be literal. The
reasons stated from the OP are no reason to use multiple ports/listeners on
a server.

Not necssarily, no.

As we are talking sockets and ports, I assumed we by protocols, you mean
udp/tcp.


Gee. Isn't that what I have been saying. You said ports are not limited,
now they are?

Where exactly did I say that ports aren't limited?

Agreed. This would be akin to sharing a mutex name or some other kernel
sync object. Somehow the other process must know what to connect to. So
you can "fix" it upfront or do it dynamically, share the info via the reg,
etc. No problems here.


My point was actually a very simple one meant to the help the OP. Via his
post, it seemed to me that he *thought, the only way you could have multiple
clients is to have multiple ports. This obviously is wrong and not needed
for stated for purpose (unless the purpose is not stated fully.) I never
said I could never think of a situation where it could be useful, nor did
anyone ask. I never say never (at least I try not to). I think we are
probably done with this. Cheers

I must have interpreted your "no self respecting server program [...]
uses ports in that manner" post overly widely then.

 

[Guest]

Woah there. I know all about TCP. I know you can have N connections on a single listening port. I have a specific reason for wanting to select random sockets
1) Because in my setup there really is no disadvantage listen dynamically on different endpoints (at this time at least), i.e. I don't need to worry about firewalling issue
2) Because it helps me keep thread communication to a minimum and as a result speeds up the serve

As far as 1000 threads for 1000 clients is concerned, you need at least one thread to read data off a Socket, no? I supposed you could have 10 threads to read 100 Sockets each, but I am nowhere near the optimization point where I would like to handle things that way. Hence the reason for minimizing the connection count at 100

I did not intend to start a firestorm with my question. I kept the details to a minimum so as to simplify the answer to the question. Thanks for the help, guys. Right now I'm using multiple listen points for this, but I'm going to analyze the changes to the architecture to see which method I would benefit from the most

My point was actually a very simple one meant to the help the OP. Via hi
post, it seemed to me that he *thought, the only way you could have multipl
clients is to have multiple ports. This obviously is wrong and not neede
for stated for purpose (unless the purpose is not stated fully.) I neve
said I could never think of a situation where it could be useful, nor di
anyone ask. I never say never (at least I try not to). I think we ar
probably done with this. Cheer

~~K

 

[William Stacey [MVP]]

No. I'm talking protocol such as NNTP, SMTP etc - except probably one

specifically for your application.

Ok. Now I understand. I would agree with this. If you want to offer
different services like SMTP, FTP, etc on the same server process, then that
would be natural. I did not see that in his post. Maybe some more detail
from Kevin as what exactly he is trying to do would be helpful at this
point.

Where exactly did I say that ports aren't limited?

Sorry, typo. "as fixed port numbers are limited" Meant to say "are"
limited. That is how this started I think.

I must have interpreted your "no self respecting server program [...]
uses ports in that manner" post overly widely then.

Kinda. We did not start out talking about different protocols like smtp,
nntp in the *same server service. These are normally provided by different
services. Again, I think we need some clarity on exactly what Kevin is
trying to do here. Kevin, if you still want to discuss, could we have a bit
more detail?
Thanks Jon.

 

[William Stacey [MVP]]

As far as 1000 threads for 1000 clients is concerned, you need at least

one thread to read data off a Socket, >no? I supposed you could have 10
threads to read 100 Sockets each, but I am nowhere near the optimization

point where I would like to handle things that way. Hence the reason for

minimizing the connection count at 100.

Are you using one thread per port (i.e. 100 threads)? This "may" (being
careful here) not be an optimal design, considering the alternatives (i.e.
async sockets, circular queues, etc)

I did not intend to start a firestorm with my question. I kept the

details to a minimum so as to simplify the answer >to the question. Thanks
for the help, guys. Right now I'm using multiple listen points for this,
but I'm going to >analyze the changes to the architecture to see which
method I would benefit from the most.

Ok. BTW, I like how your ng client formats the quotes in your replies.
What ng client are you using?
Cheers Kevin. And good luck on your project.

 

[David Berman]

The winsock error codes are in the Visual C++ Error Lookup tool. You'll
find a shortcut for it in Visual Studio Tools. Then just punch in the
error #. For example, your error 10048 means: "Only one usage of each
socket address (protocol/network address/port) is normally permitted. "

I think what you are doing is the best way to test for the availability.
If you can't open it, then it isn't available!



Meet people for friendship, contacts,
or romance using free instant messaging software! See a picture you
like? Click once for a private conversation with that person! Free
software!
www.SocialNetwork.com

 

[Jon Skeet [C# MVP]]

Ok. Now I understand. I would agree with this. If you want to offer
different services like SMTP, FTP, etc on the same server process, then that
would be natural. I did not see that in his post. Maybe some more detail
from Kevin as what exactly he is trying to do would be helpful at this
point.

I wasn't particularly addressing Kevin's particular request - more the
general "is it ever useful" point which you didn't really make in the
first place

Sorry, typo. "as fixed port numbers are limited" Meant to say "are"
limited. That is how this started I think.

Possibly. Along those lines, by the way - I reckon port numbers ought
to actually be UTF-8 strings. That way it wouldn't be too hard to
pretty much guarantee that no-one else was using your port. There are
problems involved with that (there'd need to be a length limit etc) but
it would really help, IMO...

I must have interpreted your "no self respecting server program [...]
uses ports in that manner" post overly widely then.

Kinda. We did not start out talking about different protocols like smtp,
nntp in the *same server service. These are normally provided by different
services. Again, I think we need some clarity on exactly what Kevin is
trying to do here. Kevin, if you still want to discuss, could we have a bit
more detail?

Just to clear up my protocol business - I wasn't talking about wildly
different standard protocols, I was talking about a single overall goal
which involved various different network protocols inside, which might
naturally fit on multiple ports. FTP is (IIRC) a good example of this,
with one protocol for the control, and another for the data streaming.

 

[William Stacey [MVP]]

Possibly. Along those lines, by the way - I reckon port numbers ought

to actually be UTF-8 strings. That way it wouldn't be too hard to
pretty much guarantee that no-one else was using your port. There are

Well maybe. I have seen issues with the endpoint mapper that ms uses.
Sometimes this can go wild. Think more related to nic issues more then
applications gobbling up endpoints, but that can happen too I guess.

naturally fit on multiple ports. FTP is (IIRC) a good example of this,
with one protocol for the control, and another for the data streaming.

Ok. Thanks.

 

[Guest]

I'm using the website msdn.microsoft.com/newgroups

My concern with using Queues and Async sockets is that it increases the complexity of the system and quite frankly I don't entirely trust the .NET Framework to handle this just yet. I'd rather keep the architecture simple and work on some sort of internal routing mechanism later once I know for a fact that writing this server in C# won't be my undoing

----- William Stacey [MVP] wrote: -----

As far as 1000 threads for 1000 clients is concerned, you need at least

one thread to read data off a Socket, >no? I supposed you could have 10
threads to read 100 Sockets each, but I am nowhere near the optimization

point where I would like to handle things that way. Hence the reason for

minimizing the connection count at 100.

Are you using one thread per port (i.e. 100 threads)? This "may" (being
careful here) not be an optimal design, considering the alternatives (i.e.
async sockets, circular queues, etc)

I did not intend to start a firestorm with my question. I kept the

details to a minimum so as to simplify the answer >to the question. Thanks
for the help, guys. Right now I'm using multiple listen points for this,
but I'm going to >analyze the changes to the architecture to see which
method I would benefit from the most.

Ok. BTW, I like how your ng client formats the quotes in your replies.
What ng client are you using?
Cheers Kevin. And good luck on your project.

 

[William Stacey [MVP]]

Ok. FWIW, I did a Dig client (NetDig at www.mvptools.com) completely using
c# and UDPClient and TCPClient. It is as fast or faster then dig (pretty
much the same.) Have not and still not found any issues with udpclient or
the .net socket stuff that I used. I was surprised (and happy) to find how
well the .net network classes work. Really very nice imho. TCPListener
seems to work well too, but have not really stressed it.

--
William Stacey, MVP

I'm using the website msdn.microsoft.com/newgroups

My concern with using Queues and Async sockets is that it increases the

complexity of the system and quite frankly I don't entirely trust the .NET
Framework to handle this just yet. I'd rather keep the architecture simple
and work on some sort of internal routing mechanism later once I know for a
fact that writing this server in C# won't be my undoing

 

[ozbear]

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.

By all means continue to wallow in your own ignorance.

Oz

 

[Guest]

Its not the sockets that I'm worried about. Its the Threading and Garbage collection. We spent years working with Sun to optimize the JVM for threading and garbage collection. Unless MS was taking notes (I hope they did), they would be drastically behind. I guess I'll soon find out

 

[William Stacey [MVP]]

Please explain what you mean when you say "One always listens on the same
port" and "When the connection is to be accepted, a new ephemeral port is
used to carry the traffic". Did you mean "socket" instead of ephemeral
port? A new socket is created to identify the client/server on connection.
If a server listens on 55, it can also send reply on 55 (and many clients
and firewalls count on this behavior). It does not create a new socket and
ephemeral port for the reply. That's not to say it can't be done.

 

[Guest]

Do you know of any multithreaded Server examples? I already have a SocketServer class that will accept N connections and them off to a Queue...

 

[William Stacey [MVP]]

Using Async accept with a delegate or one thread per connection examples?

--
William Stacey, MVP

Do you know of any multithreaded Server examples? I already have a

SocketServer class that will accept N connections and them off to a Queue...

 

[William Stacey [MVP]]

You probably have seen this before, but this site is good. Not .net
specific, but can easily read and convert to c#:
http://tangentsoft.net/wskfaq/examples/basics/

 

[Guest]

Neither. Something on the scale of multi-threaded message routing for a VOIP proxy

My server basically handles messages. Certain messages get treated differently and have different end-points. I have one object per "user" connection that handles all the logic for that connection. I'm doing it this way to limit the inter-thread communication. The more thread to thread chatter I have, the more likely a deadlock will occur (even when designed properly, software has bugs)

The issue at hand (for me at least) isn't how to use TCP or how to properly use TCP or how to properly listen, etc, etc. The issue that I am grappling with is proper server design with respect to the .NET Framework. How to properly pass messages between threads, etc. But all of these are future enhancements to the already existing server.