Thread: Difference between multicast and broadcast

  1. #1
    Registered User
    Join Date
    Feb 2011
    Posts
    16

    Difference between multicast and broadcast

    May I know what's the difference between broadcast and multicast? I tried reading from the internet but I find it too technical and hard to understand. In addtition, if I am trying to broadcast data out, what is the ip used? 255.255.255.255 or my network ip, x.x.x.255? Thanks.

  2. #2
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Multicast is a technique of sending identical packets to multiple clients (hense it's name)... Basically clients contact the server and their IP addresses are added to a list of recipients. When a packet needs to be sent, copies go to each recipient... While this seems like a perfectly sensible way of doing things, you need to appreciate that with 12,543,000 clients, for every packet you receive, the server has to send 12,543,000 uniquely addressed packets... Good idea but horridly inefficient.

    Broadcasting uses a special IP address and is generally confined to LAN systems. If, for example your Router is at 10.10.100.0 with an address mask of 255.255.255.0 ... then your broadcast IP is 10.10.100.255 (always the highest available address). Routers that support it are configured to forward this one address to all clients. The idea is that clients can listen on this address for servers to advertise their presence. A server would send a single packet on this address, all clients would hear it's advertisement and switch to the IP and Port given in the advertisement to connect with the server... which would then do multicasting. The broadcast address is not intended for streaming data (although nothing prevents it).

    Usage wise...
    Multicasting is used for streaming video, audio, time data, etc.
    Broadcasting is usually used for "Bootp" a protocal that allows computers to boot up from the network and as a means for a server of some kind to announce that it's ready for client contact.

    Does that help?

  3. #3
    Registered User
    Join Date
    Feb 2011
    Posts
    16
    yes. Thanks a lot. It helps me clear my doubts and can better plan my program. By the way, is it possible to use select() for UDP packets? From my understanding, I believe that we must register the socket file descriptor obtained when we accept the request to connect. Is my understanding wrong? Cause right now, the error obtained is that I am unable to use accept() for select. Thanks lots.

  4. #4
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by akira87 View Post
    yes. Thanks a lot. It helps me clear my doubts and can better plan my program. By the way, is it possible to use select() for UDP packets? From my understanding, I believe that we must register the socket file descriptor obtained when we accept the request to connect. Is my understanding wrong? Cause right now, the error obtained is that I am unable to use accept() for select. Thanks lots.
    UDP is connection-less... There is no connect, or accept protocal... you simply assume the other end is listening and send your packet.

    While this imposes the limitaiton of "no guaranteed delivery" it greatly eases the complexity of communications since you can talk to any number of other machines through a single, bound port...

    It's extremely simple... Create your socket, setup your host IP and port, bind the socket... then use sendto() and recvfrom() to communicate.

  5. #5
    Registered User
    Join Date
    Feb 2011
    Posts
    16
    So meaning that if I happened to receive two clients trying to send me the data i will only manage to receive one?

  6. #6
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by akira87 View Post
    So meaning that if I happened to receive two clients trying to send me the data i will only manage to receive one?
    Not at all... I have a server client pair on my website. It's done though UDP as I've described it to you. I've had as many a 20 clients connected to that server at once all polling and sending packets and narry a hint of problems.

    What you have to appreciate here is that TCP/IP networking is a *serial* protocal. You can only sendto or recvfrom one client at a time... no matter if it's UDP or TCP. Now as it turns out the underlying network drivers know this and will serialize the data for you so that even if two send at exactly the same instance, network buffering makes sure you receive both...

    The best thing I can suggest is that you read up on sockets and networking a bit and give it a try... do the examples in the tutorials, see it for yourself...

    http://tangentsoft.net/wskfaq/
    Last edited by CommonTater; 02-10-2011 at 08:08 PM.

  7. #7
    Registered User
    Join Date
    Feb 2011
    Posts
    16
    Thanks for the link. Is the link you provide suitable for linux OS? I met one problem while trying to run my program. My program is broadcasting data out to all the clients at the same so i would like to know are there any way I can prevent it from sending to the machine I am broadcasting since I am using it to recvfrom as well. What I did was to perform a check on my own to ignore the broadcasting. One more question I faced is that after the first msg buffer was filled with the data, the sec msg is not able to update it. Is there something wrong with my logic?

  8. #8
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    The Winsock information mostly applies to Linux as well. Both OSs take their networking from the Berkley Sockets model.

    I'm thinking you have misunderstood the concept of the broadcast IP... As I pointed out you do not want to send a continuous sting of packets on that IP address... you should send only 1 packet to say "I'm here"... You would continue to listen to the broadcast IP afterwards to hear client announcements. This means your software has to be ready to hear anything that is sent on that broadcast IP and deal with it, that is a shared address, you don't own it.

    Post your code... lets see what we can do...

  9. #9
    Registered User
    Join Date
    Apr 2008
    Posts
    90
    Quote Originally Posted by CommonTater View Post
    Multicast is a technique of sending identical packets to multiple clients (hense it's name)... Basically clients contact the server and their IP addresses are added to a list of recipients. When a packet needs to be sent, copies go to each recipient... While this seems like a perfectly sensible way of doing things, you need to appreciate that with 12,543,000 clients, for every packet you receive, the server has to send 12,543,000 uniquely addressed packets... Good idea but horridly inefficient.
    That is not how multicast works. Multicast functions in a manner similar to broadcast. The main difference is in the IP address used and how it is routed.

    A multicast IP address is in the range 224.x.x.x-239.x.x.x. The server picks an address in this range to send to, and each client registers to listen on that multicast address. Also, when a client registers to listen to a multicast address, the network stack automatically sends out an IGMP message to inform the local router. If the router is so configured, it will propagate that message to other routers. Then, when the server send out a multicast packet, the LAN sends it to any local host that is listening, and the local router will also pass it on if it knows of any listeners beyond it. In practice, most routers won't route multicast packets or IGMP messages, so multicast is typically restricted to the local LAN unless you configure the routers to allow it.

    Clients do NOT register with the server, and the server does NOT send a copy to each client individually.

  10. #10
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Clairvoyant1332 View Post
    That is not how multicast works. Multicast functions in a manner similar to broadcast. The main difference is in the IP address used and how it is routed.

    A multicast IP address is in the range 224.x.x.x-239.x.x.x. The server picks an address in this range to send to, and each client registers to listen on that multicast address. Also, when a client registers to listen to a multicast address, the network stack automatically sends out an IGMP message to inform the local router. If the router is so configured, it will propagate that message to other routers. Then, when the server send out a multicast packet, the LAN sends it to any local host that is listening, and the local router will also pass it on if it knows of any listeners beyond it. In practice, most routers won't route multicast packets or IGMP messages, so multicast is typically restricted to the local LAN unless you configure the routers to allow it.

    Clients do NOT register with the server, and the server does NOT send a copy to each client individually.
    Ummm... I'm thinking you need to give this a LOT more thought...

    It's a simple question really... Exactly how does the packet get from your server to my client without my IP address in it?

    Answer: it doesn't.

    So, yes multicast is sending identical packets to all listeners, there is an "add me" packet sent so the server knows your IP and well, golly geee, there is my IP in the header!

  11. #11
    Registered User
    Join Date
    Feb 2011
    Posts
    16
    Thanks guys... I managed to find the root of my program. But now I faced a segmentation fault upon running the codes. Do you have any reasons why it may cause this?

  12. #12
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by akira87 View Post
    Thanks guys... I managed to find the root of my program. But now I faced a segmentation fault upon running the codes. Do you have any reasons why it may cause this?
    Yes, indeed... it's obviously caused by a programming error of some sort

    Seriously... post the smallest code segment you can to demonstrate the error... lets see what we can do...

  13. #13
    Registered User
    Join Date
    Apr 2008
    Posts
    90
    Quote Originally Posted by CommonTater View Post
    Ummm... I'm thinking you need to give this a LOT more thought...

    It's a simple question really... Exactly how does the packet get from your server to my client without my IP address in it?

    Answer: it doesn't.

    So, yes multicast is sending identical packets to all listeners, there is an "add me" packet sent so the server knows your IP and well, golly geee, there is my IP in the header!
    it's not the client's IP in the header, it's the multicast IP. The server doesn't need to know the clients' local unicast IP or even how many clients.

    The clients would need to know via some out-of-band mechanism to listen on a specific multicast address, for example 230.4.4.1. Then the server sends a single packet to IP 230.4.4.1. Assuming the routers are properly configured, all clients listening on 230.4.4.1 will receive a copy of that packet, and of course if any of those clients are on the server's LAN they'll get it regardless of the routers.

  14. #14
    Registered User
    Join Date
    Feb 2011
    Posts
    16
    Code:
    recv_numbytes = recvfrom(recvfd, &instruction, sizeof(instruction), 0, (struct sockaddr*)&ocu_addr, 							&recv_len);
    		printf("recv = %d\n", recv_numbytes);
    		//printf("sizeof pw = %d\n", sizeof(pw));
    		switch(recv_numbytes)
    		{
    			case -1:			perror("recv got problem");
    							exit(1);			
    			case sizeof(bcast_msg):		{
    							//printf("This is the bcasting msg\n"); 
    							break;
    							}
    This is part of the code (thread) dealing with the broadcast msg. In this process, there's another thread that is broadcasting msg out at the same time. The broadcasting code is:

    Code:
    while(1)
    	{
    		bcast_numbytes = sendto(bcastfd, &bcast_msg, sizeof(bcast_msg), 0, (struct sockaddr*)&bcast_ip, 							sizeof(bcast_ip));
    		if(bcast_numbytes == -1)
    		{
    			perror("Error in bcasting");
    			close(bcastfd);
    			exit(1);
    		}
    The broadcast msg is an integer. Is that a way to prevent the broadcasting msg to be received by the above coding? One last question is that must the port of the client and the server to be the same to establish any form of connection?

  15. #15
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    On UDP broadcast only the server has to be listening to the broadcast IP... the port numbers have to match in that you still have to send on the same port the server is receiving on.

    1) Server uses recvfrom() to listen on the broadcast IP.
    2) The client sends 1 packet to query the server using sendto() on the broadcast IP.
    3) The server takes the client's IP and Port from the return address in recvfrom()
    4) The server responds from it's own IP and port directly to the client.
    5) The client takes the server's IP and Port from the return address in recvfrom()
    6) Since they now have each other's "direct line" normal communications can begin.

    The server never hears it's own broadcast because it never broadcasts.
    The client never hears it's own broadcast because it's not listening on that IP.

    For example:
    Network at 192.160.100.0 ...
    Netmask is 255.255.255.255
    Broadcast ip is 192.160.100.255

    Server opens socket A and binds 192.160.100.255:100 and begins recvfrom() loop.
    Server opens socket B and binds 192.160.100.10:200 and begins recvfrom() loop.

    Client opens socket C and binds 192.160.100.20:15600 and begins recvfrom().
    Client uses sendto() with target IP 192.160.100.255:100 from socket C to tweak the server.

    Server recieves packet from 192.160.100.20:15600 on socket A
    Server responds from socket B sending to 192.160.100.20:15600

    Client receives server reply on socket C from 192.160.100.10:200
    Client takes the server address (192.160.100.10:200) from that packet and begins normal communications with the server on that IP and Port.

    It's a bit of a brain twister... but it does work.
    Last edited by CommonTater; 02-25-2011 at 10:23 AM. Reason: Corrected netmask

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. IPv6 multicast example code
    By Sang-drax in forum Networking/Device Communication
    Replies: 7
    Last Post: 07-25-2005, 09:26 AM
  2. Sockets, multi home, multicast, security, complicated issue
    By ekymk in forum Networking/Device Communication
    Replies: 6
    Last Post: 08-13-2004, 02:12 AM