search

attwad / python-osc

Open Sound Control server and client in pure python
The Unlicense
513 stars 105 forks source link

TCP support #52

Closed cyberic99 closed 3 weeks ago

cyberic99 commented 6 years ago

Hello

Would you be interested in TCP support? I have some sample code which implements a TCP client

TCP would allow to lift the restriction on the maximum object size that can be sent through OSC

attwad commented 6 years ago

Thanks fwiw the size limitation does make sense depending on the network you're in (you can't really stay real time with 1gb messages floating around your network between clients...) but if that's a problem you've faced and somehow dealt with by using TCP then I guess you might not be the only one so it's worth contributing? Else you could also just post some samples here of your code or point to a forked repo (not sure how you did it) to help others for future reference. Either way thank you :)

cyberic99 commented 6 years ago

I'll post a link to my forked repo, and you'll choose if you want to integrate TCP support or rewrite some parts. One of the problems is that one member is called 'datagram', which makes no sense with TCP...

cyberic99 commented 6 years ago

Here is my fork: https://github.com/cyberic99/python-osc

There still are some issue. But what do you think?

I've basically copied UDP code and changed the needed parts. Asyncio functions have not been changed yet

bobh66 commented 8 months ago

@attwad I extended the work that @cyberic99 did to include an AsyncIO implementation of a TCP server that accepts SLIP-encoded requests, as described by the OSC 1.1 paper - https://opensoundcontrol.stanford.edu/files/2009-NIME-OSC-1.1.pdf

If I push a PR would you consider including this code? It would be really helpful for an integration with LedFx that I am working on. Thanks!

cyberic99 commented 8 months ago

hey this sounds very interesting @bobh66

so I have a question for you: In my fork, each time a TCP client sends a message to the OSC server using tcp, it opens a new connection to the server. I tried to maintain the connection opened but I get BrokenPipeErrors very fast. Are you able to maintain the tcp connection opened, in your implementation ?

bobh66 commented 8 months ago

Hi @cyberic99 - yes, I can keep the TCP connection open to process multiple messages. The handle method that gets called on the socket connection event sits in a loop reading from the StreamReader and processing messages until it receives an empty packet to signal EOF. I have not done extensive testing with large messages but it works for the small messages I need for my scenario. I'll put together a PR and push it for review. It might be a few days or a week or two.

attwad commented 8 months ago

Heya, this issue has been open for almost 4 years now :) never too late I guess! Feel free to send the PR, we can continue commenting there.

cococow123 commented 2 months ago

@bobh66 Any further updates on the TCP version? I'd love to see your implementation and if you could PR so this can be added :)

bobh66 commented 2 months ago

Hi @cococow123 - sorry for the delay, this got set aside when the project I was working on went in a different direction. I'll see if I can clean it up this week and push a PR. I want to get some unit tests and examples working.

bobh66 commented 1 month ago

@attwad @cococow123 I finally got this to the point where it is at least functional. It could probably use some further refinement but it's a start. Let me know if you have any comments or suggestions. I tested with QLab and Eos, as well as between the server and client implementations, but there may be edge cases that aren't covered. Thanks