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.
So is there a posssibility for newLisp to listen to these type of addresses?
Thank you,
Peter
UDP Multicast not working
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
(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
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
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
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 (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
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 (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
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/. 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.
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/. 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.
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/
Within the same LAN, the same subnet there is no problem using multicast. When crossing to other segments however, routers have to be enabled.
I have found a very good link, explaining the essences of UDP multicasting: 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.
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 is hosted in Denver/Colorado, so nothing to worry about :-)
Lutz
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 is hosted in Denver/Colorado, so nothing to worry about :-)
Lutz
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.
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.
-- (define? (Cornflakes))
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
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
Hello Lutz,
I did not see the 8.1.5 release befor so my last reply was a bit in advance.
Using MultiCast-groups is impossible right now :-)
As (net-listen 4096 "226.0.0.1" "multi") can only listen on 1 group,
A 'list can be the solution here to replace the ip-string.
i.e. multicast-groups looks like:
(net-listen 4096 ( "226.0.0.1" "230.1.1.20" "233.33.33.10") "multi")
Perhpas you have a trick for net-listen ? A net-select wont do the trick...
Regards, Norman.
I did not see the 8.1.5 release befor so my last reply was a bit in advance.
Using MultiCast-groups is impossible right now :-)
As (net-listen 4096 "226.0.0.1" "multi") can only listen on 1 group,
A 'list can be the solution here to replace the ip-string.
i.e. multicast-groups looks like:
(net-listen 4096 ( "226.0.0.1" "230.1.1.20" "233.33.33.10") "multi")
Perhpas you have a trick for net-listen ? A net-select wont do the trick...
Regards, Norman.
-- (define? (Cornflakes))
Well, this can be solved of course by listening multiple times:
(net-listen 4096 "226.0.0.1" "multi") => 5
(net-listen 4096 "230.1.1.20" "multi") => 6
(net-listen 4096 "233.33.33.10" "multi") => 7
...so for every IP address a different socketnumber is returned.
That means that every socketnumber points to a group.
In your newLisp program you create an array holding all socketnumbers, and with a loop you send the same message to all groups.
(net-listen 4096 "226.0.0.1" "multi") => 5
(net-listen 4096 "230.1.1.20" "multi") => 6
(net-listen 4096 "233.33.33.10" "multi") => 7
...so for every IP address a different socketnumber is returned.
That means that every socketnumber points to a group.
In your newLisp program you create an array holding all socketnumbers, and with a loop you send the same message to all groups.
hiya Pjot,
Does that work ???????
i.e.
Nice suggestion though a multicast-group listenes all together on 1 port
or more groups on more ports ...
Newlisp net-listen binds already to a port...the rest will return 'nil
(its not default to bind again on a binded port ;-)
Norman.
Does that work ???????
i.e.
Nice suggestion though a multicast-group listenes all together on 1 port
or more groups on more ports ...
Newlisp net-listen binds already to a port...the rest will return 'nil
(its not default to bind again on a binded port ;-)
Norman.
-- (define? (Cornflakes))
Report so far: preliminary tests show correct behaviour of the UDP functionality.
And what does this mean:
And what does this mean:
The net-listen command binds to an ipaddress/port combination. New net-listen commands will only return NIL if you try to net-listen to the same ipaddress/port combination again.Newlisp net-listen binds already to a port...the rest will return 'nil
(its not default to bind again on a binded port ;-)
It depends on what you mean with multicast GROUPS. A class D address already is a group. This happens when multiple users listen to that same class D address. So for example 224.1.1.1 already is a multicast group. Setting up a socket to such an IP address defines a multicast group.
But 1 socket by it's very nature cannot listen to different class D IP address and ports at the same time.
So for every individual class D IP address you have to setup a new socket. This can be realized the way described earlier.
Obviously you mean multiple multicast groups? Reaching this with 1 socket?
But 1 socket by it's very nature cannot listen to different class D IP address and ports at the same time.
So for every individual class D IP address you have to setup a new socket. This can be realized the way described earlier.
Obviously you mean multiple multicast groups? Reaching this with 1 socket?
I seems when using 'C' setsockopt(.. IP_ADD_MEMBERSHIP ...) several calls with different multicast group IPs could be isssued on the same socket, but I am not planning to implement groups of multicast groups.
Peter's suggestion to use several net-listen on the same port but with different multicast IPs, seems to be a good solution for this scenario.
Lutz
Peter's suggestion to use several net-listen on the same port but with different multicast IPs, seems to be a good solution for this scenario.
Lutz