Multiple Multicast addresses 1 socket
DynamoBen
Posts: 366
I have an application that uses multiple multicast addresses that share a port number. Normally I would open a socket with a single address and call it done, however in this case I would like to receive data from multiple multicast addresses from a single socket.
Anyone know how to assign multiple multicast addresses to a single socket?
Anyone know how to assign multiple multicast addresses to a single socket?
Comments
If you have many multicast addresses (I'm assuming that means more than one IP) then you would need as many connections. I'm not sure how to have multiple IP addresses that share the same port. You can have different IPs (multiple machines or instances) with the same port number.
What's keeping you from using two sockets?
Nothing except I'm already using all 4 and have a need for a 5th. The application listens to 4 multicast address that are constantly gathering data. I would like to have a web page served up to allow for configuration of the device but that would require a 5th socket. Ultimately I may have to build a different network interface to be able to pull this off. In the end I was hoping a spiffy work around, but that doesn't look like it exists.
I guess you could solve that with the W5100 in raw mode - in theory. In practice, I do not think this is very realistic on the propeller due to the limited resources.
Interesting idea, but you are right resources would be an issue. I will take a look, I may very well be reaching the outer bounders of the W5100 (I could use the W5300, too bad my application is using SPI).
Not sure if you are doing UDP sends or not, but I just found a bug in the UDP send portion of the SPI driver that causes some sent packets to be truncated. I started another thread on it.
-jim-
Thanks for the heads up Jim, and yes I'm using UDP. In fact you know which project I'm working on.
Would you be so kind as to post a demo of your code? I'm have all I can do just to process a single source of data.
This isn't really a port issue since all the multicast traffic goes to the same port, I would need the router to strip the IP and replace it with a different one. With that said I took a peak at raw mode which could do what I need it to. The trick would be reading and discarding all the data I'm not interested in.
I can, its very uninteresting and it won't make much sense out of context. However I'm happy to if it will help someone. With that said I recently made a bunch of changes and need to test it before I post it.
Ben have you tried raw mode? I wasn't able to make it work, but right now I don't remember how far I got with it. I remember reading something to the effect that there may be some issues with raw mode on the wiz. If raw mode was working, it would seem like you would only see (every) multicast packet. Perhaps a modified UDP read routine that would examine just enough of the packet to determine if it's one you wanted, and only then read the entire packet in, otherwise discard it.
Another idea I have tossed around: Have the web server only come up in certain situations: say after a reset, or only if a button is pressed, or if there is no activity on a socket for a certain period of time. Then the web server would time out after a certain period of inactivity and that socket would go back to receiving multicast. That way you could bring up the web server locally by resetting the board, or remotely by interrupting the multicast packets. Or it would pop up automatically if you are using less than 4 universes.
It wouldn't be as convenient as an always-up web server, but would be useable. Another was to use say 3 sockets to read packets from 4 ports using a round-robin type of scheme where after you receive a packet, you re-set that socket to look for a packet from the least recently received port. The problem with that approach is that from what I've seen, the machines that spit out the SACN packets seem to do them in a burst, then wait 25 ms, then another burst, they're not all nicely spaced.
@ jstjohnz I haven't yet tried raw mode, once I get the code I have tested I might play with that. With regard to the webserver those are good ideas, I might also be able to switch to the webserver when a "magic packet" is sent (that would be a bit of a weird hack). I had also considered using parts of the full ACN protocol to do the configuration, I haven't really looked into this very deeply. Finally I could always use the serial port or some type of physical UI.