Based on my understanding, port numbers are just like telephone extensions. Just as a business telephone switchboard can use a main phone number and assign each employee an extension number (like x100, x101, etc.), so a computer has a main address and a set of port numbers to handle incoming and outgoing connections.
But the question is:
On what basis is a port number assigned? A process or an application?
Based on my experience with firewall, I usually open a port for a specific application. So port number should be assigned on an application's basis. But what if there're multiple instances of the same application running on a single machine. Each of the instances uses the same port number. So if a message is arrived at that port number, how could the system tell which instance should the message go?
And another question also related to port.
If a web server is setup to listen on port 80, client browser should always contact the 80 port. I am not sure if the following illustration of the communication between a web browser and the web server is correct.
Client Browser sent request to Server, the message should contain info like this:
To: < ServerAddress:80 >
From: < ClientAddress:XXX >
Server sent reponse to Client Browser like this:
To: < ClientAddress:XXX >
From: < ServerAddress:80 >
So the question is, will the server pick other port numbers for sending messages to client? Because I think a single 80 port doesn't look enough.
Add - 1 - 21:16 2010/12/19
In my above post, the word "application" represents a static program file that the system knows. Multiple instnaces of this application could be launched, which are multiple "processes"
Each client connection will be represented by a socket on the server. Sockets are uniquely represented by the combination of the following 4 pieces of information:
Peer IP address
Peer port
Local IP address
Local port
The client chooses a random port, so if there are multiple connections from one client to the same server/port, the connections will still differ by the client's port.
If there are multiple web server applications running on the same server, they will have to listen on different ports or the server will need to have multiple IP addresses.
On a computer, only one process can be listening on a specific port number. For example, if an Apache process is listening on port 80, no other application can also listen on port 80.
Apache usually pre-forks several processes, only one of those is listening on port 80. The job of that process is to hand over the processing for any connection to one of the pool of other Apache processes as quickly and efficiently as it can.
Each of many concurrent connections to port 80 is distinguished by it's source IP-address and by the source TCP port number (which the client computer chooses randomly from the set not in use).
(Edit)
I was pretty sure that webservers have one process (or thread) listening which accepts incoming connections and passes corresponding filehandles to the worker processes (or threads). EJP advises that this is not so.
Apache seems to have several different multi-processing modules that affect how it spreads the load of responding to multiple concurrent requests. For example: MPM Prefork and MPM Worker
Jeff Pozkaner wrote an overview of HTTP server design that I found interesting:
The basic operation of a web server is to accept a request and send back a response. The first web servers were probably written to do exactly that. Their users no doubt noticed very quickly that while the server was sending a response to someone else, they couldn't get their own requests serviced. There would have been long annoying pauses.
The second generation of web servers addressed this problem by forking off a child process for each request. …
A slight variant of this type of server uses "lightweight processes" or "threads" instead of full-blown Unix processes. …
The third generation of servers is called "pre-forking". Instead of starting a new subprocess for each request, they have a pool of subprocesses that they keep around and re-use. …
The fourth generation. One process only. No non-portable threads/LWPs. Sends multiple files concurrently using non-blocking I/O, calling select()/poll()/kqueue() to tell which ones are ready for more data. …
Network stack distinguishes TCP connections by triple <source IP,source port,destination port>, so knowing client address and port is enough to work correctly.
What is the application, if it is not a process? In firewalls you open ports for executables. It may be considered as an application, and it is a process when it is running.
Multiple listeners cannot listen to the same port. The same process can listen to multiple ports.
Ports are assigned to the listeners. Depending on the firewall (and its configuration) you can allow the process (executable) to listen several ports, or to create several exceptions for the same process listening to multiple ports.
I'm not sure what you mean by the difference between a "process" and an "application". Everything is just code executing on your box.
Anyway, a process/application will listen/bind to whatever port number the authors of the application have configured. By convention, many port numbers are reserved for particular types of application - that is applications which communicate using a particular protocol. So for example web servers which use HTTP typically run on port 80. SMTP servers run on port 22. HTTPS is 443 and so on.
Of course you can configure your web server (e.g apache httpd) to run on whatever port you like - but your client needs to know else it will assume port 80.
Two processes/applications may not bind to the same port. If you try to start another process/application on a port already in use you'll get an error: cannot bind to port or something to that effect.
will the server pick other port
numbers for sending messages to
client?
No. All the accepted sockets use the same server-side port number as the original listening socket. The identifying tuple mentioned above disambiguates this so as to make each connection unique.
Related
I'm receiving lots of information per client, and i don't know how to handle it. If i make lots of connections to one port will it work? Now, I'm using 1000 ports open with only one client. Do I change?
Typically, one application or one major part of application should have its own port. For each client that connects to the port, you spawn a process/create a thread to service it. After the service is complete and the reply sent back, if connection is not persistent, you close it.
After all, you can only have 65535 ports open on your pc (theoretically), and not all of those are available for private (non system) applications either.
So the way to go is to have one port for application/major application functionality. E.g.
Database Management Systems (e.g. DB2) can have a (theoretical) max limit of 64000 connections per port.
http://pic.dhe.ibm.com/infocenter/pim/v6r0m0/index.jsp?topic=%2Fcom.ibm.wpc.adm.doc%2Fdata_admin%2Fwpc_con_managedb2connections.html
Multiple clients can connect to the same listening port, so you only need to open 1 port in most cases (some protocols, like ftp, use multiple ports). It is the combination of client IP/port and server IP/port that uniquely identifies a connection, so it works just fine. There are multiple programming models available to allow a server to service multiple clients at one time.
https://serverfault.com/questions/296603/understanding-ports-how-do-multiple-browser-tabs-communicate-at-the-same-time
how can an application use port 80/HTTP without conflicting with browsers?
How do multiple clients connect simultaneously to one port, say 80, on a server?
I have read the above questions but it seems the answers are inconsistent.
I want to know what exactly defines a socket connection, is it:
(sockid, source ip, source port, dest ip, dest port)
or only:
(source ip, source port, dest ip, dest port)
Can two different processes (e.g, two different browsers) communicate with a web server on the same source port? (the dest port would be the same by default)
What will happen in the case of different tabs in the same browser?
Also, as mentioned in one of the answers, a single web page can connect to multiple servers (e.g., ad servers) simultaneously. When connecting to multiple servers simultaneously, does the web browser (e.g., Chrome, Firefox) connect to each server using the same port, or does it use a different port for each server?
I know this is late, but since the thread is still on the internet, and because it's a common question with very few authoritative answers on the web, it deserves a more complete and concise explanation for those who may stumble into it, even at this late date.
You open a browser to pull up a web site, let's say google.com. In the process of specifying the web site your computer will arbitrarily pick a port number to use as its "source port." The number will be above 49152 which is the beginning of the "Dynamic, Private, or ephemeral ports" but below 65535 which is the highest port number available. The chosen port number is associated with that browser "instance."
Just for fun, you open a new tab on the browser and also type "google.com" on the url line. Your goal is to have two instances of google.com running because you're looking for different things. Your computer then chooses a second port number for that session, different from the "source" port it used for the first session. You could, in fact, do this many, many times, and each session will have a unique "source" port associated with each instance.
Your packet goes out to google.com, and the destination port number in every instance will be port 80. Web servers "listen" on port 80 for incoming connection requests. For each session with google.com you've opened, the destination port, from the perspective of your computer, will always be port 80, but for each instance of connection to google.com on your browser or browsers, the source port will uniquely identify one specific tab on one browser instance, uniquely. This is how they are differentiated on your computer.
google.com gets your first request. Its reply will specify port 80 as its source port. Here's where it gets interesting. Each query google.com received from you will be treated as a "socket," which is a combination of your IP address, and the specific port number associated with the process that contacted google.com. So, for instance we'll say your IP address is 165.40.30.12, and the source port number your computer used as its source port for four instances of communications with google.com (let's say four different tabs all opening google.com) were 61235, 62421, 58392, and 53925. These four "sockets" would then be 165.40.30.12:61235, 165.40.30.12:62421, 165.40.30.12:58392, and 165.40.30.12:53925. Each combination of "IP address:source port number" is unique, and google.com will treat each instance as unique. google.com responds to, and communicates with the "socket," that is, the combination of IP address and port.
Your computer gets its responses from google.com, and sorts them out by what it receives as its destination "socket" which it parses out by port numbers, assigning the response from google.com to the appropriate browser window or tab, as appropriate. No problem from your end of things as you see the correct response in the correct window every time.
"But," you're thinking, "what if someone else accidentally uses the same port number - let's say 61235 - as I've used for my source number? Doesn't this confuse google.com?" Not at all, because google.com is tracking "sockets" which are a combination of IP address and port number. Someone else, naturally, and we sincerely hope, is using a different IP address from the one you're using, let's say 152.126.11.27, and the combination of IP address and port number are unique - 152.126.11.27:61235 - differentiated by their different IP addresses, even though the port numbers are the same.
It doesn't matter if google.com gets 1000 queries from 1000 users, all using port 80 as their destination port number (the port google.com is listening to for incoming communications) because each of those 1000 users will all have unique IP addresses. google.com tracks its clients by their unique - and they always have to be unique, don't they? - socket numbers consisting of their IP address and "source" port number. Even if every one of those 1000 clients somehow managed to use the same "source" port number (unlikely to the max), they would still have differing IP addresses, making their source "socket" unique among all of the others.
This is all rather simple when you see it explained this way. It makes it clear that a web server can always listen on one port (80) and still differentiate from the various clients. It doesn't simply look at the IP address it received in the query - you'd think they should all be unique at first blush until you realize you could have more than one web page opened on that web server - but at the source port number, which in combination, make every query unique. I hope this is pretty clear. It's an elegant system when you think about it, yet simple once you understand it.
Taking your questions in turn:
A connection is defined by:
{ protocol, local IP, local port, remote IP, remote port }
(It's better to say local and remote rather than source and destination, because the local port is the source when you send, but the destination when you receive.)
The sockid is just a descriptor in the user process that maps to the connection in the kernel, just as a file descriptor maps to a file on disk that has been opened.
Two different processes cannot bind to the same local port. However, it's possible for two processes to use the same connection -- a socket descriptor can be inherited from a parent process to a child process, or the descriptor may be passed between processes using interprocess communications. The two processes would be using the same ports because they're actually sharing the same connection.
While the protocol allows use of the same local port when connecting to different remote servers or ports, most TCP stacks will not allow this. The API for binding a local port is the same whether you're using it for an outgoing connection or listening for an incoming connection, and the intention isn't specified until AFTER the port is bound. Since only one socket can listen on a particular port, the API simply refuses to allow multiple sockets to bind to a port (there's a special exception to this, but it's not relevant to this discussion). As a result, all outgoing connections will use different local ports. So when the browser opens multiple connections (either to the same or different web servers) they will have different local ports.
I have read the above question on respective forum but I guess people
there also do not agree with each other.
I see no disagreement in any of those concerning the matters you mention.
I want to know what exactly defines a socket Connection
( sockid , source ip , source port , dext ip , dest port )
or only
( source ip , source port , dext ip , dest port )
The latter. The former is a figment of imagination. It isn't mentioned in any of the threads you cite.
What I want to ask is that can two different processes like two
different Browsers communicate with a web server on same source
port.(Dest port would be same by default).
Not if they are at the same source IP. It would violate the identity definition stated above.
What in case of Different tabs in same browser.
Yes, because of connection pooling. If you are talking about separate connections, the answer is still no.
Also as mentioned in one of the answers a single web page tries to
connect to many different servers like ad servers etc. So does Chrome
or firefox for that matter connect with the same port to different
servers or use a single port.
You are going to have to explain this. What is the difference between 'the same port' and 'a single port'? Not a real question.
I don't really understand the differences between the different ports. I couldn't find any useful resources online that would go into detail about it. From what I can understand, it acts as some kind of filter that blocks out any other request not using the same port number.
When will I, if ever, need to change the port number when typing in a website in my browser? What about if I am running my own website? Are there any risks I take when using port 80? As in, are there ways to use different port numbers to hack into a website?
And since a Simple Mail Transfer Protocol uses port 25, could I use this knowledge to send emails using self written programs?
By conventions and standards, defined protocols generally listen on defined ports by default. You can set any service to listen on any port you want, just be aware that changing from a standard port means that standard tools would need to be explicitly told to use your non-standard port.
For example, if you run a web server then by default it's probably listening on port 80. So all someone needs to do to visit your server is use the address:
http://www.yourserver.com
However, if you change it to listen on a non-standard port, such as 81, then any user who wants to visit your site will need to specify the port number:
http://www.yourserver.com:81
The standard convention of just using the address wouldn't be sufficient, because you've broken convention. Now, this is fine if you don't want people randomly using your site and only want it to be available to people to whom you've told the port number. This is called "security through obscurity." It doesn't actually secure your site in any way or filter out anything, it just adds an additional step to the use of the site.
As for SMTP, yes, you can write programs to connect to port 25 on SMTP services and send data to those services. You may indeed be able to spoof emails in this manner. However, most services have other built-in checks and balances to prevent such spoofing.
TCP/IP supports 2^16 ports on a machine. A server program is said to listen on a specific port; other machines contact a server program at a machine using the port number and the name of the machine. It's like the address on a letter.
Some port numbers are "well known", which just means they're officially assigned for a particular service: port 80 is for web servers, port 25 for SMTP, port 25 for telnet, etc.
But any server can run on any port; it's just a matter of changing the code or the configuration. Sometimes you may way to run two separate web servers on one machine; one might listen on port 80, and the second one on some other port (8080 is a common choice for servers used during development.)
So the client can't meaningfully change the port to some random number: there has to be something listening on that port, on that machine, or it doesn't do anything.
There is no 'difference' between running a web server on any port number, from a purely technical perspective, as long as the client and the server both know which port to use. When the client connects to the server, it has to know the IP address as well as the port.
By convention, several ports are used by standard services. For example, port 25 is SMTP, port 80 is the http port, 22 is the ssh port, etc. Because of these conventions, ports less than 1024 are reserved by the operating systems and can only be opened by a root process.
Unless there is a specfiic reason, it is generally a good idea to stick with the standard port numbers. Advanced port scanners/ analysis tools will try all ports on a system, so there isn't much benefit to running a service on a non-standard port.
The port numbers are a way of multiplexing communications over IP links. This is commonly used to provide specific services on accepted port numbers. HTTP servers have been allocated port 80 for listening for incoming client connections, though this is not a lock - there is nothing stopping you constructing/configuring an HTTP server that listens on port 9001, or whatever. If you did use a non-standard port number for your server, then you would have to specifically instruct a browser to connect to that port, rather than defaulting to 80 as it normally does.
SMTP in port 25 using your own program - sure, you can do this. Any mail app is some developers' 'own program' .
Rgds,
Martin
This question already has answers here:
Does the port change when a server accepts a TCP connection?
(3 answers)
Closed 4 years ago.
I understand the basics of how ports work. However, what I don't get is how multiple clients can simultaneously connect to say port 80. I know each client has a unique (for their machine) port. Does the server reply back from an available port to the client, and simply state the reply came from 80? How does this work?
First off, a "port" is just a number. All a "connection to a port" really represents is a packet which has that number specified in its "destination port" header field.
Now, there are two answers to your question, one for stateful protocols and one for stateless protocols.
For a stateless protocol (ie UDP), there is no problem because "connections" don't exist - multiple people can send packets to the same port, and their packets will arrive in whatever sequence. Nobody is ever in the "connected" state.
For a stateful protocol (like TCP), a connection is identified by a 4-tuple consisting of source and destination ports and source and destination IP addresses. So, if two different machines connect to the same port on a third machine, there are two distinct connections because the source IPs differ. If the same machine (or two behind NAT or otherwise sharing the same IP address) connects twice to a single remote end, the connections are differentiated by source port (which is generally a random high-numbered port).
Simply, if I connect to the same web server twice from my client, the two connections will have different source ports from my perspective and destination ports from the web server's. So there is no ambiguity, even though both connections have the same source and destination IP addresses.
Ports are a way to multiplex IP addresses so that different applications can listen on the same IP address/protocol pair. Unless an application defines its own higher-level protocol, there is no way to multiplex a port. If two connections using the same protocol simultaneously have identical source and destination IPs and identical source and destination ports, they must be the same connection.
Important:
I'm sorry to say that the response from "Borealid" is imprecise and somewhat incorrect - firstly there is no relation to statefulness or statelessness to answer this question, and most importantly the definition of the tuple for a socket is incorrect.
First remember below two rules:
Primary key of a socket: A socket is identified by {SRC-IP, SRC-PORT, DEST-IP, DEST-PORT, PROTOCOL} not by {SRC-IP, SRC-PORT, DEST-IP, DEST-PORT} - Protocol is an important part of a socket's definition.
OS Process & Socket mapping: A process can be associated with (can open/can listen to) multiple sockets which might be obvious to many readers.
Example 1: Two clients connecting to same server port means: socket1 {SRC-A, 100, DEST-X,80, TCP} and socket2{SRC-B, 100, DEST-X,80, TCP}. This means host A connects to server X's port 80 and another host B also connects to the same server X to the same port 80. Now, how the server handles these two sockets depends on if the server is single-threaded or multiple-threaded (I'll explain this later). What is important is that one server can listen to multiple sockets simultaneously.
To answer the original question of the post:
Irrespective of stateful or stateless protocols, two clients can connect to the same server port because for each client we can assign a different socket (as the client IP will definitely differ). The same client can also have two sockets connecting to the same server port - since such sockets differ by SRC-PORT. With all fairness, "Borealid" essentially mentioned the same correct answer but the reference to state-less/full was kind of unnecessary/confusing.
To answer the second part of the question on how a server knows which socket to answer. First understand that for a single server process that is listening to the same port, there could be more than one socket (maybe from the same client or from different clients). Now as long as a server knows which request is associated with which socket, it can always respond to the appropriate client using the same socket. Thus a server never needs to open another port in its own node than the original one on which the client initially tried to connect. If any server allocates different server ports after a socket is bound, then in my opinion the server is wasting its resource and it must be needing the client to connect again to the new port assigned.
A bit more for completeness:
Example 2: It's a very interesting question: "can two different processes on a server listen to the same port". If you do not consider protocol as one of the parameters defining sockets then the answer is no. This is so because we can say that in such a case, a single client trying to connect to a server port will not have any mechanism to mention which of the two listening processes the client intends to connect to. This is the same theme asserted by rule (2). However, this is the WRONG answer because 'protocol' is also a part of the socket definition. Thus two processes in the same node can listen to the same port only if they are using different protocols. For example, two unrelated clients (say one is using TCP and another is using UDP) can connect and communicate to the same server node and to the same port but they must be served by two different server processes.
Server Types - single & multiple:
When a server processes listening to a port that means multiple sockets can simultaneously connect and communicate with the same server process. If a server uses only a single child process to serve all the sockets then the server is called single-process/threaded and if the server uses many sub-processes to serve each socket by one sub-process then the server is called a multi-process/threaded server. Note that irrespective of the server's type a server can/should always use the same initial socket to respond back (no need to allocate another server port).
Suggested Books and the rest of the two volumes if you can.
A Note on Parent/Child Process (in response to query/comment of 'Ioan Alexandru Cucu')
Wherever I mentioned any concept in relation to two processes say A and B, consider that they are not related by the parent-child relationship. OS's (especially UNIX) by design allows a child process to inherit all File-descriptors (FD) from parents. Thus all the sockets (in UNIX like OS are also part of FD) that process A listening to can be listened to by many more processes A1, A2, .. as long as they are related by parent-child relation to A. But an independent process B (i.e. having no parent-child relation to A) cannot listen to the same socket. In addition, also note that this rule of disallowing two independent processes to listen to the same socket lies on an OS (or its network libraries), and by far it's obeyed by most OS's. However, one can create own OS which can very well violate this restriction.
TCP / HTTP Listening On Ports: How Can Many Users Share the Same Port
So, what happens when a server listen for incoming connections on a TCP port? For example, let's say you have a web-server on port 80. Let's assume that your computer has the public IP address of 24.14.181.229 and the person that tries to connect to you has IP address 10.1.2.3. This person can connect to you by opening a TCP socket to 24.14.181.229:80. Simple enough.
Intuitively (and wrongly), most people assume that it looks something like this:
Local Computer | Remote Computer
--------------------------------
<local_ip>:80 | <foreign_ip>:80
^^ not actually what happens, but this is the conceptual model a lot of people have in mind.
This is intuitive, because from the standpoint of the client, he has an IP address, and connects to a server at IP:PORT. Since the client connects to port 80, then his port must be 80 too? This is a sensible thing to think, but actually not what happens. If that were to be correct, we could only serve one user per foreign IP address. Once a remote computer connects, then he would hog the port 80 to port 80 connection, and no one else could connect.
Three things must be understood:
1.) On a server, a process is listening on a port. Once it gets a connection, it hands it off to another thread. The communication never hogs the listening port.
2.) Connections are uniquely identified by the OS by the following 5-tuple: (local-IP, local-port, remote-IP, remote-port, protocol). If any element in the tuple is different, then this is a completely independent connection.
3.) When a client connects to a server, it picks a random, unused high-order source port. This way, a single client can have up to ~64k connections to the server for the same destination port.
So, this is really what gets created when a client connects to a server:
Local Computer | Remote Computer | Role
-----------------------------------------------------------
0.0.0.0:80 | <none> | LISTENING
127.0.0.1:80 | 10.1.2.3:<random_port> | ESTABLISHED
Looking at What Actually Happens
First, let's use netstat to see what is happening on this computer. We will use port 500 instead of 80 (because a whole bunch of stuff is happening on port 80 as it is a common port, but functionally it does not make a difference).
netstat -atnp | grep -i ":500 "
As expected, the output is blank. Now let's start a web server:
sudo python3 -m http.server 500
Now, here is the output of running netstat again:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN -
So now there is one process that is actively listening (State: LISTEN) on port 500. The local address is 0.0.0.0, which is code for "listening for all". An easy mistake to make is to listen on address 127.0.0.1, which will only accept connections from the current computer. So this is not a connection, this just means that a process requested to bind() to port IP, and that process is responsible for handling all connections to that port. This hints to the limitation that there can only be one process per computer listening on a port (there are ways to get around that using multiplexing, but this is a much more complicated topic). If a web-server is listening on port 80, it cannot share that port with other web-servers.
So now, let's connect a user to our machine:
quicknet -m tcp -t localhost:500 -p Test payload.
This is a simple script (https://github.com/grokit/dcore/tree/master/apps/quicknet) that opens a TCP socket, sends the payload ("Test payload." in this case), waits a few seconds and disconnects. Doing netstat again while this is happening displays the following:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN -
tcp 0 0 192.168.1.10:500 192.168.1.13:54240 ESTABLISHED -
If you connect with another client and do netstat again, you will see the following:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:500 0.0.0.0:* LISTEN -
tcp 0 0 192.168.1.10:500 192.168.1.13:26813 ESTABLISHED -
... that is, the client used another random port for the connection. So there is never confusion between the IP addresses.
Normally, for every connecting client the server forks a child process that communicates with the client (TCP). The parent server hands off to the child process an established socket that communicates back to the client.
When you send the data to a socket from your child server, the TCP stack in the OS creates a packet going back to the client and sets the "from port" to 80.
Multiple clients can connect to the same port (say 80) on the server because on the server side, after creating a socket and binding (setting local IP and port) listen is called on the socket which tells the OS to accept incoming connections.
When a client tries to connect to server on port 80, the accept call is invoked on the server socket. This creates a new socket for the client trying to connect and similarly new sockets will be created for subsequent clients using same port 80.
Words in italics are system calls.
Ref
http://www.scs.stanford.edu/07wi-cs244b/refs/net2.pdf
In short: How to reliably discover a server running somewhere on a (presumably multi-segmented) local area network with zero client configuration
My client application has to locate the server application without knowing the server IP address. It has to work on a local LAN that may be split into segments with hubs or other switching devices.
I already have a working solution, but it is a bit cumbersome to get it working on multi-segment networks. It works as follows:
When the client starts up, it sends UDP broadcasts on its own network segment. If the server is running on the same segment, it works without any issues - the server responds with the appropriate messages.
If the server and client are running on networks separated by a hub / switch that won't forward UDP (the most likely case), then I have a server instance running on each segment, and they forward client requests to each other via TCP - but I need to configure this for the server instances (simple, but still a pain for tech support.) This is the main problem that I need to address. There are sites where we have hundreds of clients running on 5 or 6 separate segments.
The problems I'm facing:
1. Although my application installer enables the appropriate ports on the firewall, sometimes I come across situations where this doesn't seem to happen correctly.
2. Having to run multiple server instances (and therefore configure and maintain them) on hub/switched networks that won't forward UDP
Finally I need a solution that will work without maintenance on a minimal Windows network (XP / 2000 / Vista) that probably doesn't have Active Directory or other lookup services configured.
I don't want to tag on any runtime stuff for this - should be able to do it with plain VC++ or Delphi.
What approaches do commercial apps usually take? I know that SQL Server uses a combination of broadcast and NetBEUI calls (I may be wrong about this).
Thanks in advance.
You have a few terminology issues:
Where you say "network segment" you appear to mean "IP subnet". Devices on the same network segment can see the same IP broadcasts.
Where you say "hub/switch" you appear mean "IP router".
Where you say "won't forward UDP", the problem is actually "won't forward IP broadcasts".
Once we get past that, you have a few options:
Your servers could register themselves under a well-known name in DNS, if you have a DNS server that allows dynamic DNS updates. You should probably use a SRV record as specified in RFC2782. The clients then do a DNS lookup to find the server(s).
You could statically assign your server(s) well-known names in the organisation's DNS, perhaps with a SRV record as with the previous option.
Your servers could join an IP multicast group, if your routers support IP multicast. The clients then send their initial discovery request as a UDP packet to the (pre-ordained) multicast address.
If you have domain server, I would go with small service on it. You can connect with other services to it and use it as distribution point.
Why domain server? It is relatively easy to find it's name (DsGetDcName).
Other choices would include DHCP server, DNS server or something of that kind that needs to be filled by maintenance staff anyhow.