First a little on terminology. UDP is
connectionless, if you are using TCP then you can wait on a connection, but with
UDP there is no connection. You can't wait on a connection, the client
can't make a connection. All they do is (server) listen for incoming
packets and (client) send data packets.
I think you're missing a little bit of basic
networking concepts. Your server is listening on 4010, so it's side of the
net communication looks like this: A.B.C.D:4010. The client doesn't have
to use it's local port 4010, it's port number doesn't really matter as long as
it's above 1024. Windows cycles through port numbers as they are requested
by applications. When you are listening (server) you need to specify an
exact port because that's the port the clients will send data to. When you
are the client it doesn't matter what port number you send data from, just as
long as you are sending it to the correct server port. So the client's
side looks like this V.W.X.Y:Z.
So the way both ends (and firewalls and other
network devices along the way in the network) identify this particular
communication is by combining the server IP:PORT and client IP:PORT. The
server application knows which client is sending the data by the client's IP and
port number, if you run two clients on the same machine they will be given
different local port numbers even though they connect to the same server port
number. If you start the clients at the same time you can expect one of
them will get port Z and the other one Z+1, just because when they call the
socket functions to begin communications with the server windows will hand them
the next port numbers that haven't been used and aren't currently in use.
If you start two servers they will have to listen
on different ports because two applications can't listen to the same local port
(just like two applications can't send on the same local port either).
Otherwise when data comes in to a port how can the OS tell which app to give it
to? It can't if it allows them to use the same ports to listen to.
Likewise how would a server distinguish two clients sending from the same port
on the same system except they be given different port numbers? It
can't.
So typical TCP/IP stacks allow listening sockets
to request their listening port number and that port will be granted *if* it's
not currently in use (by either another app listening app or a client that just
happened to use that port to send from) and (on *nix systems depending on your
config) if the port is less than 1024 you must be root (these are privileged
ports).
When a client socket is created it is given the
next socket number available, and the tcp/ip stack just dishes it out.
Even when a client socket is closed the tcp/ip stack won't reuse it until it has
cycled through all the socket numbers and come back around to it. Usually
this is done because the other end may have the socket marked as open and will
try to do a rst (reset) after a set timeout. If that socket was reused too
quickly it may receive that rst and the stack wouldn't know what to do
since that rst IP is not a part of the current client/server IP/port
pairing. I've seen rst packets that came as long as 24 hours after the
connection was successfully closed. Why the other end still though the
connection was active was puzzling to me.
So what I suspect you are seeing is your
listening server gets 4010 as requested and your client is being given the next
available number according to that computer's local tcp/ip stack. After
you close that client and start it up again the tcp/ip stack just dishes out the
next number. Not unusual at all.
Sorry if the above is a lot of ramble, I hope you
can make sense out of it.
|
_______________________________________________ msvc mailing list [email protected] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
