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

Handles client sockets for streaming in a separate thread #39

Closed
cedricve opened this Issue May 2, 2016 · 2 comments

Comments

2 participants
@cedricve
Copy link
Member

cedricve commented May 2, 2016

Implement multithreading to handle incoming client sockets, this will solve the blocking client problem with Tablets and Smart Phones.

History

Problem

I think that the raspberry pi continues to be busy trying to handle previous requests for the live stream and these requests do not ever stop trying to be handled by the pi since it is a live stream request. I suspect that new requests to view the live stream queue up behind the original request, and since the first request is never completed, all subsequent requests are not completed.

Here is the case: I got the live stream to work for the first time in my browser. Then I asked my son to try to access the live stream on his iPhone (the live stream did not appear for him). I then asked my other son to try on his Android phone and he did see the live stream. When I went back to my browser, the live stream was no longer showing on my browser. So I tried to access the live stream from another browser on my laptop, and also my iPad. Sometimes is shows, most times the live stream does not show.

Answer

Your assumption is correct, it's indeed possible that a thread can block the streaming for other clients. We did not implement a separate thread that handles the different clients (for simplicity), and apparently this is causing the problem for your situation.

The situation you describe is exact what I mean; the problem with tables and smartphones is that they support background processes. An example: if you open a game with your IPad or Android Phone and go back to the homescreen, the process isn't actually closed. The game is still available (in memory), and you can re-open it very quickly, this is the idea of multi-tasking. If you we take the Kerberos example: your son opens the browser or another app to open the livestream, and goes back to the homestream. Because the process isn't closed, the socket isn't closed either, and it keeps alive. This causes the client socket to go in sleep mode (timeout), and as we didn't implemented threading, it will block the complete streaming process.

@cedricve cedricve self-assigned this May 2, 2016

@cedricve cedricve added the bug label May 2, 2016

@matt-biskup

This comment has been minimized.

Copy link

matt-biskup commented May 5, 2016

May I suggest that there is a time-out setting for the live feed? Perhaps a function that kills the live feed request after a certain length of time? I'm thinking that the system is not set up to kill a live feed.

Even if there were multiple requests that succeed after you implement the fix in the next release, there is likely no need for the live feed to continue indefinitely. It is using resources on the Raspberry Pi and the network the Raspberry Pi is on - whether the live feed is successful or unsuccessful. In either case (success or fail) the process of providing a live feed should terminate at some period of time similar to how the cloud.kerbios.io system times out.

Perhaps this time period becomes an option in the Settings panel:
<Live_feed_terminates_after_minutes>5</<Live_feed_terminates_after_minutes>

MB

@cedricve

This comment has been minimized.

Copy link
Member

cedricve commented Jun 7, 2016

We've added a fix that will make send a non-blocking function, to be tested..

@cedricve cedricve closed this Sep 20, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment