Chat keeps on waiting when partner do not reply

[Akash3194]

Everything works perfectly but only 1 issue i got is, there is not time parameter in side "chat.get_event()", if user does not reply it keeps on waiting. I am here to request to add a time limit here. Thanks

[coal0]

Sorry, I'd love to help you here, but unfortunately this is just a very tough piece of code to update. The only feasible way to implement a timeout would be to add threading, but I remember when I tried that a couple of years ago it did not work out well, especially considering all the additional functionality was implemented on top of the current blocking system. I'll try to see if I can find a way around this problem. If I find a solution, I'll give you an update here. No promises though. In the mean time, you could try tinkering with _get_events() yourself to see if you can wrap it in a timeout thread (presumably with a Lock/Condition/Semaphore).

[toniokroeger]

Couldn't the timeout be introduced in the requests.post()-call in _get_new_events(), which takes a timeout parameter?

[coal0]

Couldn't the timeout be introduced in the requests.post()-call in _get_new_events(), which takes a timeout parameter?

I must admit that I've forgotten some of the intricacies of the Omegle protocol, but I'm fairly sure this would not work. The problem lies in the complexity of the Omegle API and my own sloppiness. For whatever reason, the API likes to behave in unexpected ways, for example, churning out empty event queues, splitting or splicing messages, holding back messages until more events are gathered, etc. From the client's point of view, this is all seemingly random, but realistically it probably has something to do with things like server loads, connection times and timeouts. Because of this, events should not be considered reliable, even if they seem to be most of the time. There has to be an independent thread for keeping time, and even then the issue is not truly resolved because the cause of the timeout is simply unknown. To account for this, an entirely new system would have to be thought out, written, coded, tested, fixed and published again, along with a new README and reference.

To be perfectly honest, I never intended to make a completely infallible copy of the private API, and so when I got basic functionality working, I figured I'd just keep it as it was for fear of introducing even more bugs. Unfortunately, this seems to be the nature of reverse engineering: you think you have it all figured out and on the 100th test run, something new breaks. To redesign this entire package from the ground up in order to eliminate all bugs and stay as close as possible to the original Omegle experience would be difficult, but probably not impossible (assuming there is some kind of fundamental consistency to the API), and certainly would be very rewarding. My schedule has been quite busy and I don't think I can fit such an undertaking in any time soon, but hopefully I can work on it in the future, along with other projects.

[toniokroeger]

My workaround is to use multiprocessing and kill the process when the timeout occurs, but that is not the most elegant solution, I'm afraid. :)

[coal0]

Indeed, but then a design problem arises: you can only start the process when you're connected to a stranger, so you have to wait for a CHAT_READY event which is part of the public interface. The developer does not (should not) have access to the underlying functions such as _get_new_events(), which would have to be modified. Either you would break the public interface by catching the CHAT_READY, or you'd have to force the developer to dive into the package code themselves. I guess this isn't a huge deal-breaker but I'd like to keep the API as clean as possible.

In conclusion, this is likely feasible, but would involve a pretty serious overhaul (I haven't tested it recently, the last time I tested it didn't work for whatever reason. It might have been because I was using the lock incorrectly, but I didn't bother debugging at the time).

[coal0]

Closing this issue for now. This is something I will look into if I ever get around to redoing this whole project. Any further input is welcome (by email).