Skip to content
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

multiple apps listening on the same UDP port #13

Open
marcobrianza opened this issue Mar 27, 2019 · 7 comments
Open

multiple apps listening on the same UDP port #13

marcobrianza opened this issue Mar 27, 2019 · 7 comments

Comments

@marcobrianza
Copy link

marcobrianza commented Mar 27, 2019

Hello, thank you for this great library.

I have the case where 2 processing applications running on the same computer need to receive messages on the same UDP port.

In my test with current version only the first application launched receives the messages.

In other cases using an artnet library in processing I was able to receive UDP messages on the same port. It might relate to an option to "reuse" the socket address. I think that the artnet library does it in this point:
https://github.com/cansik/artnet4j/blob/c923f4bd01e89d8912515d38407f6a875944f04a/src/main/java/ch/bildspur/artnet/ArtNetServer.java#L170

Is there a similar option in ocsP5?

Thank you
Marco

@marcobrianza marcobrianza changed the title multiple apps listening on the same port multiple apps listening on the same UDP port Mar 27, 2019
@pbai-engineering
Copy link

I have the same issue and would love to know if there's a simple solution.

@cansik
Copy link

cansik commented Jun 18, 2020

@marcobrianza Of course this could be implemented. The base for oscp5 and artnet4j are the java sockets.

But to be honest, there are more issues than just this one, here a list of things that I would love to see:

  • bind to a specific network interface
  • broadcast support for datagram socket is not enabled
  • oscEvent method swallows error messages
  • bundles are not supported
  • performance issues for sending out packages (always recreating a datagram socket)
  • verbose logging clutters the terminal

And the fact that this library has not been updated since years is also not great. Maybe it makes sense to rewrite it based on a already existing and well supported OSC implementation like hoijui/JavaOSC.

@marcobrianza
Copy link
Author

Hi @cansik thanks for joining this thread, My Java level is really low, so I cannot handle to make a processing library.
I'm using your artnet library in a software that receives osc messages from touchosc and controls lights with artnet.
If you come up with an updated OSC processing library please let me know. see you. Marco

@trackme518
Copy link

trackme518 commented Apr 17, 2024

Hi, @marcobrianza I have already offered merge with my update of oscP5 library but it is probably abounded by maintainer. However, thanks to your comment I was able to create a non-blocking version from last Sojamo source code. You can find modified library that can coexist on the same port in my fork: https://github.com/trackme518/oscp5/releases . I have also added function to print the incoming IP with m.getIP() call.

@marcobrianza
Copy link
Author

hi @trackme518 thank you for the enhancement! I'll test it in the next project

@trackme518
Copy link

hi @trackme518 thank you for the enhancement! I'll test it in the next project

How did it went? Can you star the repo so it's easier for others to find? https://github.com/trackme518/oscp5 thanks

@marcobrianza
Copy link
Author

Hi I think I have not used yet OSC in processing since a long time because I'm using MQTT lately. I have starred the project. Ciao!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants