Re: Socket connect vs. bind? What is the difference

Actually, if you're doing UDP Multicast, you don't need to connect. UDP is a
connectionless protocol.

Let me explain a little bit. Network IP communications involve 2 processes
on 2 different IPEndPoints. Each IPEndPoint represents an IP address and a
Port number. They can be on the same or different machines, as long as each
is unique. TCP is a connection-oriented protocol, which requires the client
to call Connect to establish a TCP connection to the remote IPEndPoint. UDP
is connectionless, so it isn't even necessary to establish a connection to
the remote IPEndPoint.

The Bind method is used to associate (or "bind") a Socket to a *local*
IPEndPoint. In the case of the "server," there is a single process bound to
an IPEndPoint. In the case of the "clients" there is generally one "client"
per client IPEndPoint. Each Socket sends to a remote IPEndPoint and receives
from its own local IPEndPoint.

The Sockets class is fairly flexible, and can be used in any of several
ways. In some cases, there is no "right way," but may be several "right
ways" to communicate, particularly in the case of UDP. The local IPEndPoint
can be set in any of several ways. For example, a client can Bind to a local
IPEndPoint, which means that the client picks the Port it is bound to
(associated with). It can be set with an overload of the Socket constructor.
It can be set by calling "Connect," but again, you don't need to call
"Connect" to interact with a multicast server. UDP allows each member to
just begin sending and receiving. It is up to the processes to know what to
expect from the remote process, when to send, what to send, when to receive,
and what to receive. Dropped packets must be handled by the process, as the
protocol doesn't handle them. It is basically a very primitive, but
fast/powerful network protocol. It requires the processes to be more
responsible for themselves, but the payoff is in the communication speed.
Data is sent and received in DataGrams.

Here are a couple of references concerning UDP and multicast that may help:

http://msdn.microsoft.com/msdnmag/issues/06/02/UDP/
http://zeus.osix.net/modules/article/?id=409

And the RFC for UDP:
http://www.faqs.org/rfcs/rfc768.html

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.

"DaTurk" <mmagdits@xxxxxxxxxxx> wrote in message
news:1149710750.837789.20260@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Yes, but what if your just subscribing a socket to a multi cast group.
So that the one socket will send to the group, and many sockets will be
able to read from the group. Would you need to connect as well? And
does it matter that it's multicast over UDP?

And not to sound daft, but I still don't really understand the
difference between associating with and endpoint rather then connecting
to an endpoint. Thanks again for the reply.

Kevin Spencer wrote:
That's correct, because the listener is the server. You can have multiple
clients connect to the server socket. It's a little more complicated than
that, but basically, you want to bind your server to the server socket
and
set it to Listen. Then your clients will Connect to the server socket to
interact with the server application. The server calls Accept for each
client that it wants to accept when they attempt to connect. Each client
will have its own IPEndPoint, which is made up of an IP address and a
Port.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.

"DaTurk" <mmagdits@xxxxxxxxxxx> wrote in message
news:1149705354.184570.195770@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks for the reponse, but what exactly do you mean by associate, and
connect. I guess what I'm asking is what is the difference, and when
would you want to use one over the other, what situations.

At this point I'm using sockets to create a multicast socket server
setup, and in examples I saw, the socket that sends typically connects,
and the socket that listens binds.




.

Relevant Pages

  • Re: Socket timeout on recv()
    ... > My program just listens on a UDP (connectionless) socket so I haven't ... > tested closing a connected socket. ... timeout if possible), handle errors and reconnect ...
    (microsoft.public.windowsce.embedded)
  • RE: Implementing a UDP Message Receiver
    ... SOMAXCONN is irrelevant for UDP because a UDP is ... connectionless. ... the server is not really waiting to listen on the socket ...
    (microsoft.public.win32.programmer.networks)
  • Re: Asynch Sockets over UDP: How do you Know when a socket dissconnects
    ... UDP is unreliable and *connectionless*. ... but the packets may simply disappear into the ether. ... That is, at the low level of the BSD socket API, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: SetSockOpt with SO_REUSEADDR parameter
    ... So I create multiple UDP sockets with the same port to send data. ... happening is that you are throwing away the old socket and replacing it with the new ... When the second client is connecting to server, I still get the error code ...
    (microsoft.public.vc.mfc)
  • Re: Strange UDP Socket problem
    ... You can catch that exception and move on. ... never get any udp reply back to post an exception. ... >> I suspect you would get the same response if you used one thread to send ... >> thread on same socket. ...
    (microsoft.public.dotnet.languages.csharp)