-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Teensy 4.1 QNEthernet - Multi universe receive issue #12
Comments
Minimal examples: Only one instance, both of the multicast groups are received properly.
Second example with 2 instances. The second will always throw the error.
|
Sorry that I can't help you because it is a problem with QNEthernet. |
This likely has something to do with the fact that there’s only a single network interface in the QNEthernet library at this time, and only one socket can be bound to a single port at a time. This means that, from the perspective of the stack, there’s only one place to receive data sent to a specific port, regardless of how it got there, either via multicast or via a specific non-multicast IP address. From the discussion there, it sounds like the pure Wiznet stack operates a little differently, where you need one UDP socket per multicast input, even for the same port. I’m working with @sstaub on this. (Please correct me if I got any details wrong.) Basically, the solution right now is to only have one UDP socket per port, depending on the library, somehow making a determination which underlying network library is being used. I’ll think more about this. |
Hi,
I'm trying to make a multi-universe receiver using this library, but I see a collision.
Based on the sACN example, the proper way to do this is by using multiple EthernetUDP instances, like this:
EthernetUDP sacn1;
EthernetUDP sacn2;
EthernetUDP sacn3;
EthernetUDP sacn4;
However, if I check the QNEthernet readme:
Since only one socket at a time can be bound to a specific port, you will need to use the same socket if you want to receive traffic sent to multiple groups on the same port. You can accomplish this by either calling beginMulticast(ip, port) multiple times, or by using begin(localPort) once, and then calling Ethernet.joinGroup(ip) for each group you want to join.
So if i make multiple EthernetUDP instances, only one of them can subscribe to multiple multicast groups, the rest will fail from the second.
If i try to use only one EthernetUDP instance and bind the Receivers to them, the multicast subscription seems fine, but the first parsePacket() in the sACN library eats the packets, and drops it, so the other Receiver objects can't read them.
The text was updated successfully, but these errors were encountered: