Strange Migration from W2->W3 Problem

[randall]

"This order seems to be deterministic, it is always the same"

Seems pretty strange. Perhaps using a packet sniffer to see the order of TCP packets will lead to some insight.

[TrebWalker]

I used Wireshark to have a look into the RTMP- packets:

The order of the AMF-Properties in the packet "AMF3 Shared Object" is the same as it appears in the client. But as the packet in Ubuntu is transfered as one piece, the SLES-packets are sent in smaller parts. And: There is always a "[TCP Retransmission] AMF3 Shared Object after each packet, which includes the same information as the original one.

I am no expert in these things - what does this mean?

thanks,

Treb

[TrebWalker]

It seems as if the TCP retransmissions were caused by my virutal machine. Some sniffing done on our live Wowza3 shows none of that.

But the evidence is clear now: the _result() RTMP-Packet I receive from a Wowza3 installed on Ubunutu/Mac/Windows is different from the one I get from a Suse Linux (maybe all rpm-based Linuxes?) - at least in the standard configuration.

So your software behaves different depending on the OS. Do you intent to investigate that issue or do I have to find a workaround for that?

Treb

[randall]

"TCP Retransmission" means the receiver did not get the next packet it was expecting.. that indicates a network issue. However, that should not result in out-of-order packets.

Take a look in the AS3.0 docs at SharedObject.mark():

Delivers all changeevents to a subscribing client as a single message.
In a server-side script, you can call the SharedObject.setProperty()method to update multiple shared object
properties between a call to the lock()and unlock()methods. All subscribing clients receive a changeevent
notification through the SharedObject.onSync()handler. However, because the server may collapse multiple
messages to optimize bandwidth, the changeevent notifications may not be sent in the same order as they were in
the code.

My hunch is that this is an OS peculiarity, and not a bug. As mentioned in the API, you will have to account for this behavior in your code.

[rrlanham]

For finer and richer control you can use IApplicationInstance.broadcastMsg, IClient.call, IMediaStream.send on Wowza server-side, and NetConnection.call and NetStream.send in Flash AS3. Take a look at the ServerSideModules example for reference.

Richard

[TrebWalker]

Good news: I was able to isolate and solve the problem:

The Java version seems to be responsible for that behavior. Suse uses IBM Java, if you replace it by the "original" Oracle Java everything works as expected.

So a good advice for all serverside Wowza developers: Never change your Java vendor.

Thanks for your support,

Treb