|
First, you're getting the terminology
wrong. In udp there is no "connection" so the client can't create a
socket and connect to anything.
Hmm I not sure that is right. I think we
may be talking about two different things here. I'm talking about making
a connection on a connectionless socket (confused yet?) Reading page 207
of the "Network programming for Microsoft Windows"... states...
//------------------------
Another method of receiving (and sending)
data on a connectionless socket is to establish a connection. This might
sound strange, but it's not quite what it sound like. Once a
connectionless socket is created, you can call connect or WSAConnect with the
SOCKADDR parameter to set the address of the remote machine to communicate
with. No actual connection is made,
however.
So my contention is there there is no
connection. "No connection is made" = "No connection".
The socket address passed into a connection
function is associated with the socket so that recv and WSARecv can be used
instead of recvfrom or WSARecvfrom because the data's origin is known.
The ability to connect a datagram socket is handy if you intend to communicate
with only one endpoint at a time in your
application.
Does your app only communicate with one
client? After that client hangs up, will another client
connect?
//-------------------------
It creates a socket and sends data to
the server addr/port. Look at the ::bind( ) Remarks in help.
You'll note that only for tcp if the port is specified as 0 that windows
will assign the port number. You see, in udp this just isn't
necessary. In tcp you can only have one app receiving and sending data
on a particular port. But with udp you can have several apps all
receiving data on the same port, and yes it's a pain to be avoided but is
possible (at least you can do it in UNIX). So I think for the bind
call in udp you have to specify the port even for the
client.
So you think I have to call the bind call on
the client as well as the server and specify the port I think it should
use?? This may well be correct. When I bind the client side to a
port no the program works, its just coincidence that it is the same port no as
the server.
If it's working, why not just use it that
way?
Yeah, pretty much - just the odd niggle that's
been bugging me - such as the bind thing.....
I would do the bind but not the connect.
Even with what that author wrote, the connect just "locks" you down to talking
only to one IP/port and it's not necessary and doesn't really "connect" you at
all.
| 