it's my understanding that all RTMFP functions should work just the same on iOS (via the packager) as on any other platform. however, i don't use any iOS devices nor do i have any first-hand experience using the packager.
there should be discussion forums for the packager for iOS. i would start there.
note that my "example" from that thread was supposed to be illustrative, not actual running code. if you just wrapped up those code snippets as-is into functions or something, i can imagine you might not be keeping your NetConnections or NetStreams or other objects anchored appropriately to avoid garbage collection. i can imagine GC on iOS to be much more aggressive than on the desktop, given the more constrained memory situation.
you're totally right: "all RTMFP functions should work just the same on iOS", iam with you, but it does not.
For me it is hard to say wether it it a rtmfp, air or ios packager bug, thats why i posted it here.
If you could point me to the iphone packager forum? that would be great, i cant find it!
As you can see from my code, i'm not doing anything fancy, nor do i "not keeping other objects anchored appropriately to avoid garbage collection", look here: http://codetidy.com/791
its a really simple example which works on web, air launcher, but not on ios after packaging, so i'll try my best to find some person at the ios packager team to adress this to.
i agree, it doesn't look like you should be having any GC issues.
one thing i noticed is your onPeerConnect() function doesn't return a value. it must return true in order for a subscribing peer to be able to attach to your publishing stream.
another thing is your NetConnection status handlers don't seem to be paying attention to the event.info.code, and will treat success and failure (and any other events that might come along) as success (calling checkNetConnectionsReady(), and incrementing _netConnectionCounter, which on the second call will make your code think that both NetConnections are ready whether they are or not). that way of handling those events is very fragile and will be super sensitive to even tiny differences in timing. in ncOutStatus i would always trace the event.info.code, not just when _myPeerSenderID is undefined.
there used to be an iOS packager forum, but it appears to be closed/archived now. the current AIR mobile development forum appears to have postings about iOS and other platforms:
when you say you can't make two NetConnections at the same time: what happens? do they both fail? does the second one fail? does the first?
youre absolutely right in the two things you mentioned.
1.) For the sake of simplicity i stripped out all NetConnection status handlers, to see if the net connection worked or not or what else happened.
But if i write the trace output in a textfield on ios i see that everthing works fine on the first place, and my super lame check if both connections are ready works there, both are connected successfully.
2.) onPeerConnect return value:
"onPeerConnect() function doesn't return a value" => that is right, but it does not make a difference on ios even if they return true;
the corrected script on: http://codetidy.com/794 reflects that, but it does not work.
What i meant with two concurrent NetConnections not working meant was, that it is just not working when using rtmfp.
It worked on the ipad when i used the traditional rtmp client / server streaming via red5 though.
the rtmfp on ipad fails, when ipad is the sender and another device or itself is the receiver. then after a call to:
and therefore the _recvStream.play( "stream" ); method, i dont get a netStatusHandlerReceiver event back on the receiver side, nor does a onPeerConnect method on the sender does get triggered.
But one thing stays quite strange:
if i setup my ipad packaged air file as a receiver and receive a stream from another air file on my laptop via cirrus it works.
if i setup my ipad packaged air file as a sender and send the stream to another air file on my laptop via cirrus it does not work.
so there seems to be a bug in the ios packager and rtmfp part.
thanks for the link, but its just not my use case. different story, so unfortunatly it does not help me.
i don't see anything obvious in your currently posted code that could be the problem.
i have a hypothesis, but i need your help to test it.
please temporarily modify your program to make an RTMFP NetConnection to "rtmfp://cc.rtmfp.net/", and print out the NetConnection.nearID for that connection to cc. then please post the peerID for your problem iDevice to this forum (it's cryptographically pseudorandom and once your NetConnection is closed, the peerID is gone forever, so there's no harm in posting it publicly).
i will use that peerID to find your test results and other network interface information about your device in cc.rtmfp.net's logs. that will either confirm my hypothesis or help me further diagnose the problem.
Great, any Ideas are very welcome!
An iPhone OS 4.3.3 iPad2,1 NetConnection.nearID is:
Iam eager to hear if you can see anything in the logs.
thank you. i found your information in the log.
unfortunately my hypothesis was proved. it appears AIR for iOS (or at least on your device) doesn't sent its local interface (behind-NAT) address(es) to the server. if your NAT doesn't implement "hair-pin" translation forwarding (where two devices behind the same NAT can communicate using the outside-NAT address), then without the local interface addresses it won't be possible to make a P2P connection to that device from another device behind the same NAT. that includes two RTMFP instances on the same computer (such as your test).
this limitation should only affect P2P communication between devices that are behind the same NAT. you should be able to publish a stream P2P to a device that's not behind the same NAT, or if the publishing iOS endpoint is not behind NAT. bidirectional communication would also be possible between devices behind the same NAT if the iOS device *also* subscribed to a P2P stream from the other device *and* the other device was not iOS.
i consider this missing functionality a bug. i have opened a bug report against the packager for iOS.
i looked into this a little deeper. it appears that the normal Mac OS X APIs one uses to discover the local interface addresses (among other system configuration information), the APIs in SystemConfiguration.framework, aren't available on iOS.
we will investigate other possible ways of collecting this information. i don't have direct access to the iOS developer tools and SDK, but it appears from publicly available developer documentation that the getifaddrs() call is available on iOS, and that should provide the necessary information assuming it functions as expected. i have noted that in the internal bug record.
thanks a lot for your efforts!
Is there any way to get notified of the bug's report status?