Socket connect vs. bind? What is the difference

[DaTurk]

I am makeing a Multicast server client setup and was wondering what the
difference is between Socket.Connect, and Socket.Bind.

It may be a stupid question, but I was just curious. Because I tried a
test, and I can't bind two sockets to the same port/ip but I can
connect with one socket, and bind with another to the same ip/port.

Thanks

 

[Kevin Spencer]

Bind associates a Socket with a local IPEndPoint. Connect connects a Socket
to a remote IPEndPoint.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Development Numbskull

Nyuck nyuck nyuck

 

[DaTurk]

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.

 

[Kevin Spencer]

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]

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]

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]

I understand the majority of what your saying. Right now I have two
classes inheriting from a base class which has the connect method for
the socket. The two child classes represent a sender, and a receiver.
Now, say I want to test this sender receiver locally, I kinda have it
set up to default to values for testing puposes. And I don't want to
use 127.0.0.1. Both send and receive use the same connect method.
When I say connect, it's really bind and connect depending on a flag.
Here, maybe looking at the code might help. Here's the connect method.

private bool Connect()
{
bool connectSuccessful = false;
IPAddress localIp = null, remoteIp = null;
try
{

//Making sure the remoteIP is there, otherwise using a default.
if(this._multiCastIP == null || this._multiCastIP.Length <= 0)
{
remoteIp = IPAddress.Parse(MCAST_ADDRESS_A);
}
else
{
remoteIp = IPAddress.Parse(this._multiCastIP);
}

//Making sure the localIP is there, otherwise using a default.
if(this._localMachineIP == null || this._localMachineIP.Length <= 0)
{
localIp = GetLocalIP();
}
else
{
localIp = IPAddress.Parse(this._localMachineIP);
}

//Making sure the port is there, otherwise using a default.
if(this._port == null || this._port.Length <= 0)
{
this._port = MCAST_PORT_A;
}

//Just making sure the Time TO Live is greater then 0
if(this._multiCastTtl <= 0)
{
this._multiCastTtl = DEFAULT_TTL;
}

_socket = new Socket( AddressFamily.InterNetwork,
SocketType.Dgram,ProtocolType.Udp );
IPEndPoint ipep = new IPEndPoint(localIp, int.Parse(this._port));
if(this._isSend)
{
_socket.Connect(ipep);
}
else
{
_socket.Bind(ipep);
}
_socket.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReuseAddress, 1);


MulticastOption mcastOption = new MulticastOption( remoteIp, localIp
);
_socket.SetSocketOption( SocketOptionLevel.IP,
SocketOptionName.AddMembership, mcastOption );
_socket.SetSocketOption( SocketOptionLevel.IP,
SocketOptionName.MulticastTimeToLive, this._multiCastTtl );
connectSuccessful = true;
}
catch(Exception ex)
{
Console.WriteLine(ex.ToString());
}

return connectSuccessful;
}

sorry about the bas formatting, and here are the default values I use.
plus, I just grab the local IP address of the machine I'm on.

public static String MCAST_ADDRESS_A = "227.1.2.3";
public static String MCAST_ADDRESS_B = "227.5.7.11";

public static String MCAST_PORT_A = "6203";
public static String MCAST_PORT_B = "6204";

Now, if I try to run both on the same box, with both the send and
receive binding to the same IP/PORT I get an error, but if I connect
the sender, I don't. I really appreciate the help.

 

[Kevin Spencer]

I told you, the client and server do not share the same IPEndPoint (IP
Address and Port).

Also, you should remember that I told you that UDP is a connectionless
protocol, and there is no need to call Connect.

If you look at the 2 tutorials I referenced, you'll notice that Connect is
never called in either one.

I would suggest simplifying your code and making sure that the simplest form
of it is solid before adding all the complexity. The more variables there
are in a problem, the more points of failure there are, and the harder it is
to isolate the problem. You might benefit from reading the following article
on Wikipedia about Unit Testing:

http://en.wikipedia.org/wiki/Unit_testing

The basic principle (like so many basic principles) is simple: Test each
piece before you try to combine them. This will save you from getting grey
hair at an early age, and speed up your development process as well!

While it is not necessary to follow the patterns and procedures mentioned in
the article and related links, it is very important to understand the KISS
principle of Unit Testing. I, for example, over many years, have developed
my own methodology for Unit Testing (long before it became part of the "Pop
Programming Culture" buzz-word dictionary), and use it whenever I do
development. As my Uncle Chutney sez, "Big things are made up of lots of
Little things." Make little things. Test them and make sure they work. Then
put a couple of little things together. Test that and make sure it works.
Add more little things to it. Eventually, you will have eaten the elephant,
one byte at a time (and in far less time, without getting indigestion!).

Perhaps a good start might be to take the code from the MSDN article
verbatim. Run it. Make sure it works. Tweak it to something closer to what
you're working on. Test that. Tweak some more. Test that. Before you know
it, you'll be standing on the top of Mt. Everest, wishing you had documented
the code along the way. ;-)

Another alternative (easier but less instructive) would be to use the
System.Net.Sockets.UdpClient class. This is a little higher-level class
which handles most of the low-level Socket work for you. See:

http://msdn2.microsoft.com/en-us/library/system.net.sockets.udpclient.aspx

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.

 

[DaTurk]

Thank you very much for the information, I really appreciate the
assistance.

 

[DaTurk]

One more question, I read through the examples you sent me to, and I
found them very helpful, but was a little curious about a couple
things.

In all the examples, when doing a MultiCast send the socket never binds
to the endpoint it creates, it just sends to it. Is it not good form
to bind while sending?

I was under the impression you needed to create a localendpoint to the
local address of the machine, in case there were multiple NIC's in the
machine, And bind to that, then create a MultiCastOption with the
multicast address, and the local address.

like this
MulticastOption mcastOption = new MulticastOption( remoteIp, localIp );
_socket.SetSocketOption( SocketOptionLevel.IP,
SocketOptionName.AddMembership, mcastOption );

 

[Kevin Spencer]

Well, like I said, there are multiple ways to do things with these classes,
and when you do something one way, certain things are not seen, while, when
you do it another way, different things are not seen. Under the covers, it's
all performing the same basic tasks via WinSock API calls. Sockets are
highly configurable, the basic building blocks of networking, and they can
play many different roles, using a wide variety of connection types (or not
connected), low-level protocols, and mid to high-level protocols. That's why
IP packets are called Packets. Each packet contains data that contains other
data and so on. HTTP, for example, is a high-level protocol that runs under
TCP, which uses an IP packet for transport, using Sockets. The IP packet
contains IP information, as well as a sub-packet of TCP data that contains a
sub-packet of an HTTP protocol message.

Depending upon what sort of network operation you're doing, one method or
another might be more convenient. If you think of Sockets like letters of
the alphabet, the English alphabet contains only 26 letters, but the
Dictionary contains millions of words that are made by combining those
letters in different ways.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.

 

[DaTurk]

Thanks again for helping me. I do understand the in and outs of the
protocols etc.. I;ve been a developer for the last two years, but all
of my experience has been ceneterd on thin client. Now I have a job
working with thick client, and I've just learnt how to use C# Async
methods and all that good stuff; hence I'm new so I'm a tad confused of
some of the nuances.

My app works, it's just I want it to work in a debug regard. What it
does is it has a sender, which there will be only one, will send info
via a UDP multi cast to multiple recipients subscribed to a given
muticast group. Now, when it's in productio it will work because all
of the little recipients will have different local ip's but, I want to
be able to test it locally with more then one recipient running.

That's ultimately where I'm confused. I understand that each socket
needs a distinct endpoint of it's own. So, any suggestions on how to
do this? Is it possible?

The only reason I think it is is because I've been supporting this
other app and I created several recipients all using 127.0.0.1:10002.
Although they were asynch connecting over TCP/IP, so I don't know.

 

[Kevin Spencer]

Sure, it's eminently possible. Remember that an IPEndpoint is a combination
of an IP Address and a Port. Since there are 65,536 TCP ports on any given
machine, you could theoretically test it against 10's of thousands of
clients using the same (local) IP Address and different ports.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.

 

[DaTurk]

I figured out how to do it, if you set the socket option ReuseAddress
to true it will allow you to bind multiple sockets to the same IP/PORT.

This is what I needed to do, thanks for the help.

On a side note, would you mind elaborating on what the difference is
between bind and connect? You said before that bind associates with an
endpoint, while connect connects to an endpoint. But I'm not entirely
sure what that means. I mean I know what it means, but I don't
understand exactly what one stops me from doing or allows me to do over
the other one.

 

[Kevin Spencer]

Bind is associated with a *Local* IPendPoint. Connect is to establish a TCP
Connection with a *Remote* IPEndPoint. It's really a matter of convenient
semantics.

Every network exchange occurs between 2 different IPEndPoints. There really
isn't always that much of a difference between "local" and "remote" as far
as that is concerned, other than the fact that "local" refers to the
EndPoint belonging to a process, while "remote" refers to the EndPoint of
another process. It's kind of like the terms "me" and "you." To *you* "me"
is you, but to *me* me is me. It's the same with "Local" and "Remote". If
you think of a network connection as a phone call, "Local" is you, and
"Remote" is whom you are talking to.

Now, before you decide to ask me "what about conference calls," I suggest
you study up on it on your own! ;-)

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.