UDP Multicast not working

[pjot]

Hi everybody,



When I try to receive UDP packets on a multicast IP address, newLisp seems not able to capture this. E.g.:



(set 'tmp (net-receive-udp 54000 128 udp-timeout "224.1.1.1"))



...does not assign the incoming packets to the variable 'tmp'. (I have put the value of 'udp-timeout' to 50000.)



I tested it with 2 machines, from 1 machine I send a UDP packet to IP address "224.1.1.1", which is a class D address. On the other machine I run Ethereal, which shows me that the packet actually arrives at the interface.



However, the newLisp command above seems not be able to recognize this packet.



The multicast address "224.1.1.1" is not used by any device yet; see the list of multicast address at http://www.iana.org/assignments/multicast-addresses">http://www.iana.org/assignments/multicast-addresses.



So is there a posssibility for newLisp to listen to these type of addresses?



Thank you,



Peter

[Lutz]

You have to use .255 on the sender side i.e



(net-send-udp "192.168.1.255" 2000 "Hello" true)



 .255 would send to all addresses in that subnet.



'broadcast' is something different than 'multicast addresses' mentioned in your link starting with 224.



The fact that you see a packet in Ethereal if both machines are on the same subnet. Ethereal puts the interface card in promiscuous mode to see all packets floating around, even if not addressed to the card.



What I want to say is, in newLISP you have to send to the specific subnet of the receiver and ending in .255.



did you also specify the 'true' for broadcast mode at the end?



lutz

[pjot]

Hi Lutz,



I know a broadcast is different, but I really would like to use multicast.



The disadvantage of broadcast is that it reaches ALL the hosts in the subnet. With multicast, you can reach a group WITHIN a subnet on a specific (multicast) IP address in a different range (224.0.0.0 and higher).



I did not use the TRUE flag however, I will try that now with a multicast address (so not ending with .255 at the end, but an address in the class D range).



Peter

[Lutz]

I think you have to put your network adapter into multicast mode during intialization, using a multicast address alone will not work.



Lutz

[newdep]

Hi plot,



You have to enable multicast in the Linux kernel to make it working.



The multicast is furthermore not always enabled by default by your ISP.



If you want to do "Mbone" technologie then its a different story too...



Norman.

[pjot]

Hi everybody,



Obviously this item is not clear, so let me explain more. Why does someone wants to use multicast anyway? Apart from many complicated reasons, let me give a simple example using the newLisp UDP chat demo program.



If 2 different machines (A and B) use the UDP chat, they send UDP packets to eachother. This happens according the 'send&pray' principle. So there is no acknowledgement from the other side. Now, what happens when a 3rd person (C) uses this UDP chat? C can reach A for example. Now A will receive UDP packets from B and also C. But: A cannot send UDP packets to C, because he already has specified the IP address of B.



The obvious solution appears to be for A to start the UDP chat another time. So A has to start a second UDP chat, in which he can specify the IP address of C, to which he sends UDP packets. Unfortunately this will not work, since the 'net-receive-udp' of the first instance already is listening to the UDP port, thereby blokcing the 'net-receive-udp' of the second instance. Besides it's ugly, 2 applications consuming memory and CPU, presenting the same thing.



However, there is a nice way out: multicast.



With multicast, 2 or more users can specify a class D address  on which they listen. When a 3rd person wants to join, this person also specifies the same multicast address. Now sending a message to this multicast IP address will reach everybody at the same time.



Again, this is an IP address completely different from the actual subnet where the hosts are in. Normally, a '224.0.0.0' address is used for multicast; there are international standards specifying the node-types listening to these addresses (see the URL of my first post).



Norman: for Linux this is no problem, nothing in the kernel has to be enabled. With my tests this afternoon I used a Windows machine and a Linux laptop (Fedora), both equipped with Ethereal. When I perform a 'net-send-udp' the packet with the class D destination address '224.1.1.1' actually arrives at the interface, as I could trace with Ethereal. Both on Windows and on Linux.



Lutz: I do not need to do anything extra with my NIC to receive multicast packets. My tests worked 'out-of-the-box'.



Of course, there is no application running which captures the UDP packet with address '224.1.1.1'. This is where newLisp comes in. Since for newLisp, it is only necessary to perform a receive on the interface, with a filter on the specified multicast address.



Maybe you think this is not possible. But here is my joker: with Java it actually IS possible to capture multicast IP address. Please take a look at the Java documentation at http://java.sun.com/j2se/1.4.2/docs/api/index.html">http://java.sun.com/j2se/1.4.2/docs/api/index.html (select 'java.net' upper left, and then 'MulticastSocket' on the lower left). With Java you have a so-called class which is able to listen to Multicast addresses.



Of course, there is no physical interface which is configured with an actual class D address. It's all software. But if a multiplatform language like Java can do it, why not newLisp?



Technically, I do not see a problem. It's just a matter of adapting the current newLisp implementation so TCP/UDP packets with another destination address can be captured. Maybe a new command must be created for this (net-multicast-receive).



It's more a matter if you, Lutz, want to have this feature in newLisp. Maybe this thread should be called 'Feature Request: Network Multicasting'. Please let me know how you feel about it.



Regards



Peter

[pjot]

Norman is right: indeed in my Slackware 2.4.26 kernel this is an option (Networking options/IP: Multicast). There the following is mentioned:



This is code for addressing several networked computers at once, enlarging your kernel by about 2 KB. You need multicasting if you intend to participate in the MBONE, a high bandwidth network on top of the Internet which carries audio and video broadcasts. More information about the MBONE is on the WWW at                           http://www-itg.lbl.gov/mbone/">http://www-itg.lbl.gov/mbone/. Information about the multicast capabilities of the various network cards is contained in Documentation/networking/multicast.txt.



Here the videoconferencing stuff is mentioned as multicast application.

[pjot]

Norman discovered that Rebol and Ruby also are able to handle multicast packets.



I have found a very good link, explaining the essences of UDP multicasting: http://www.tack.ch/multicast/">http://www.tack.ch/multicast/



Within the same LAN, the same subnet there is no problem using multicast. When crossing to other segments however, routers have to be enabled.

[Lutz]

I am looking into it,



Lutz

[Lutz]

Multicasting is basically done and seems to work fine on Win32 MinGW and Linux Mandrake.



In the functions net-listen and net-connect "multi" or "m" can be specified instead of "udp". This will enable UDP multicasting communications. On the sending (client) side additionally a TTL (Time To Live) value can be specified to avoid the multicast going out to the entire world  (but they say that some routers won't forward multicasts anyway).



Only little change was necessary to enable this. It was mostly using setsockopt() to put sockets into the correct modes.



I still want to do some testing for 8.1.15 and there are also timeout-value bug fixes for Solaris and BSD for net-select and net-receive-udp.



There is also hurricane Francis coming upon us here in Florida and will need some attention/preparation around the house. They say it is multiple the size of Charly 2 weeks ago on the Florida west coast and even bigger than Andrew/1992. Francis may cover most of Florida.  I may be offline for some period because of missing electricity and/or DSL connection, or my computer  is blown into the Florida swamps (not please!).



In any case I will post 8.1.5 as a development release before the Hurricane strikes probably Friday night or Saturday. http://newlisp.org">http://newlisp.org is hosted in Denver/Colorado, so nothing to worry about :-)



Lutz

[pjot]

Hi Lutz!



I am happy to hear you have decided to add the multicast functionality to newLisp! As soon as 8.1.5 is released I will test it.



Good luck with surviving the hurricane...



Cheers



Peter

[newdep]

Hello Lutz,



Good luck upcoming weekend...



Norman.

[newdep]

Hello Lutz,



The implant should work ;-) Although its good to know for the people

who will use Multicast that you can/have to create "multicast groups" to the

interface multicast is enabled on. (can simply be done in 'lists in newlisp by the users i guess, for a checkup ) in order to serve with multicast.



Regards, Norman.

[pjot]

Hi Lutz, just one more question: with "net-listen" and "net-connect" the UDP multicast is socket oriented?

[Lutz]

The socket is just a handle for communicating. Internally the socket is associated with you network interface card ip-address and a port number. On the server/listen side a 'C' function setsockopt() makes sure that the socket is also associated with the correct multicast address.



Because multicast is UDP, you use 'net-receive-from' on the server side to retrieve the source address of the client. 'net-receive' would also work, but then you don't know where the message is coming from. Only in TCP/IP unicast mode the local connected socket has info about both the local and remote address and 'net-peer' could be used.



;; example server



(net-listen 4096 "226.0.0.1" "multi") => 5

;; optionally put net-select or net-peek here ;;

(net-receive-from 5 20)  => ("hello" "192.168.1.94" 32769)



; (net-receive 5 'buff 20) ; would work but you don't get the source ip



On the client side setsockopt() puts the sending socket in multicast mode and the the multicast address is bound to the socket the same way as a target address under unicast communications is bound using the 'C' functions bind() or connect().



;; example client



(net-connect "226.0.0.1" 4096 "multi") => 3

(net-send-to "226.0.0.1" 4096 "hello" 3)



; (net-send 3 "hello") ; would also work





The multicast specific stuff happens during net-connect / net-listen when binding the sockets and supplying socket options.



The subsequent net-send-to/net-receive-from or net-send/net-receive do not know about multicasting only about UDP. Multicasting is always UDP.



Many routers suppress UDP. Multicasting seems to be more suited for well-known intra-net / campus-net where you deal with a known collection of machines and you have control of the routers.



Lutz