Closed andrewmk closed 3 months ago
The recent update introduces a sophisticated threaded mechanism for managing client connections within the server architecture. This enhancement not only allows for efficient output queue management and thread termination but also incorporates a smart timeout feature that disconnects clients based on their inactivity duration, ensuring smoother operation and resource optimization.
Files | Summary |
---|---|
ynca/.../server.py |
Introduced threaded handling for client connections, output queue management, thread termination, and a timeout mechanism for disconnections. |
🐇✨
In the land of code, where the bits do roam,
A rabbit hopped in, making server its home.
With threads it danced, and queues it played,
Whispering to connections, "Here, you shall stay."
But fear not the idle, for time is wise,
A gentle timeout, under moonlit skies.
🌙💻
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
This seems a quite complicated way to achieve a timeout. Is there no simpler way?
Disconnecting clients after some timeout is quite common and would expect that there would be a way to set timeouts and then the server would take care of this (even on the basic TCPServer example this is based on).
There might well be a simpler way - I'm by no means an expert Python programmer. I looked into the source of the readline method that blocks and the class it's part of and couldn't see a way of making it non-blocking but as I say I'm not an expert. That would be a lot simpler if you could do it.
I browsed a bit through the Python docs and found a way to just set a timeout value. I added it in PR #16 .
Just curious, is there a special reason you need the timeout? I never really had a need so never implemented it.
I added it because that's how actual Yamaha amplifiers work and it's in the YNCA spec, and someone developing a driver for Yamaha AVRs hasn't got access to one himself so having a simulator that behaves as closely as possible to a real one is a real boon. I was so pleased when I came across your project and it had the simulator.
Presumably you're still working on the PR as I can't see how the timeout is set?
I made a separate PR for it as I was not sure how it would work if I tried to add to this one. It was merged in this commit https://github.com/mvdwetering/ynca/commit/2e301ac78f804e1b54bd517d08e58a0665fa2f06
Basically add a timeout to the RequestHandler class and handle the TimeoutError exception to print a proper message..
In case you did not see already, You might be interested in the PRACTICALITIES.md document in the docs directory. I try to keep track of unexpected behavior I encountered with some specific models or just unexpected behavior in the protocol.
Btw keep in mind that, while it is quite helpful, this is in no way a perfect simulator. It just responds with whatever data it has seen before there is (almost) no validation at all. E.g. setting an input to "INVALID INPUT" will be accepted without error. Also things like the automatic sending of values when powering on a zone or switching to an input subunit are not implemented. There is probably more, but those came to mind.
Wow that was easy. I couldn't see that despite looking through the docs and source code. I'm glad you found the proper way of doing it.
I realise the simulator isn't perfect but I think it will help the chap writing a driver to have something that insists on disconnecting - he'll have to deal with that with a real AVR. Thanks.
This change makes the YNCA simulator disconnect after 40 seconds of no commands as per the YNCA spec document. I'm a complete novice with threading so this might not be the best way to do it but it seems to work.
Summary by CodeRabbit