In essence, Flash Player is a language runtime environment, similar to the Java JRE. We provide a set of low-level APIs, and content and application developers write ActionScript that exercises those APIs. Under most circumstances, there's ample room for the content provider to implement reasonable retry and error handling strategies, and to give just a little context, Flash Player's networking support is robust enough to handle commercial-grade video streaming for everyone from HBO to the NFL.
In addition, in most instances, the browser is mediating all of the network access. Flash Player is asking the browser for resources on the network, and the individual browser and/or operating system is doing the heavy lifting of making connections, implementing the appropriate networking protocol, etc. As you can probably guess, this means that there are nuanced quirks specific to particular operating system and browser combinations. To put it in context, there are something like 36 variants of Flash Player that we ship, and 6-9 distinct variants that your students would most commonly be using. Our role is to smooth out the warts across all of those platforms to the extent possible so the developers can focus on building great experiences, but the specifics definitely matter when trying to understand low-level behavior in the runtime itself.
More importantly, "getting booted out of the room" doesn't tell us anything about Flash Player itself. That's a symptom of a problem in the higher level application. All I can tell you based on the information that you've provided is that "something happens", and business logic in the conferencing software returns the user to the lobby. All I that can really infer with confidence from that is that we didn't crash. To me, that indicates that the problem could probably be caught and handled by the application itself.
If I were to take a SWAG, it would be that they have a flaky backend service (e.g. they built a cloud-based backend that uses a distributed database that's configured to prefer availability over consistency, and they've used it for maintaining user state, such that critical user state evaporates depending on which node the request goes to), and/or they're not implementing a robust-enough recovery strategy to handle adverse conditions in your network environment, and should maybe catch networking exceptions and retry them over a long timeout period before declaring the failure state that leads them to return the user to the lobby.
What I am fairly confident about, is that our networking APIs provide the ability to build a robust implementation that works in real-world conditions, but before you can have a conversation about what needs to get fixed, you need to understand exactly why it fails, and you're not going to do that easily as an outside observer.
A conversation with your vendor is in order. Ideally, they already have logging that can tell you why users get booted to the lobby constantly. If not, there are facilities available (Local Shared Objects, etc.) that they could leverage to store information about fatal errors on the local machine until they start talking to the client again, at which point, they could collect them.
If, in the unlikely event that the vendor discovers an language-level issue that needs our intervention, they're in a position to have detailed information about the failure itself and the scenario that leads to the failure. Without that, we're just blindly guessing about stuff, which isn't going to get your problem solved. They're more than welcome to reach out to me directly (they can send a PM by clicking my username), and I'd be happy to get a conversation going at an engineering level.
4
Replies
AdChoices