Remote Shared Object: Changes not send to server anymore

[dpMediaDev]

Hello,

6 month ago I tried to prove some bug in the Wowza shared object communication using a test application I posted here: http://www.wowzamedia.com/forums/showthread.php?t=5457
But this didn't help very much because the issues are hard to provoke.

Now the features we want to implement based on shared objects get more important. But if it doesn't work reliably we think about doing our own shared object implementation using client2server and server2client calls.

Well, I don't want to reimplement all that stuff (including the applications on top of this layer) so I still try to figure out where and when the problems occur. Now I put a lot of debug logging in the code to see what really happens if the issue occurs.

To sum it up:
For any reason, a client can get suddenly "disconnected" from a shared object in a way that the client to server communication gets disabled while the other way round (server to client comm.) still works perfectly.
So you get all changes to the SO communicated by the other clients but you can't send your own changes anymore. SetProperty(), SetDirty(), etc. affecting only your local SO instance but the server gets no message at all (I used some packet sniffer to validate this).

I have no idea if this problem is initiated by the client or the server. But I know how you can simulate it: There is a fps property in the SharedObject class of the Flash client so you can change the sync timer frequency, that means how often local changes are communicated to the server.
If you set fps to 0 then Flash's sync timer stops so your SO changes are not delivered to the server. This feels exactly like the explained issue from above.

In this simulated case you can still catch up so all changes are delivered to the server by setting fps > 0 again. In my case you can't do anything but reconnect the whole client.

If the problem is client related I wonder why the sync timer to send updates to the server should fail. Or maybe the server has an option to quit client2server communication on a SO but why should it do that?

A possible workaround would be to watch if the property changes really produce messages by checking if the client got some success messages in his SO sync event handler using a time out. Unfortunately there seems to be no other way to check if setProperty() was successful, it's just a method without a return value.

Hopefully anyone has an idea...

Sincerely,
Robin
dpMediaDev

[dpMediaDev]

In the meantime I rewrote my test application so it can discover shared object modification problems itself. So I can start it on several clients and just wait till a problem occurs.

Summary: Sometimes (at least every 1-2 minutes or so) operations on a shared object (creating, changing or deleting slots) have no effect to the other clients and you don't get a success or delete message as a confirmation. I also tested it using the trial version of Adobe's Flash Media Server and I get the same results so it's not only Wowza related.
I don't know if this issue leads to my problem from above (communication in one direction ist lost at all) but at least it's a strange behaviour which can cause other difficulties.

So does this mean, all the shared object communication isn't reliable at all? I don't know what this technology internally does to prevent those problems but it seems not to be stable at all. At least in Adobe's bug database I can't find anything related to this.

I wouldn't have a problem when some changes are note communicated to all clients (think of some coordinates of a space ship) because some moments later the data is refreshed anyway. But if you create a new slot (like creating a new space ship) and all the other clients don't see it at all is more defective.

Well, now I try to prevent loss of information by triggering timers to verify if a corresponding success/delete message has been arrived. I do this only in the crucial parts of my code because it also means some overhead.

Sincerely
Robin
dpMediaDev