Salman Abdul Baset wrote: > Thanks for the excellent answers. Couple of comments inline with some > snips: > > >> 2) TCP isn't supported, because it doesn't make any sense to run RTMFP >> over TCP. RTMP exists and works over TCP, but only for the client-server >> cases. > > So presumably the DHT put/get operations are less than a MTU so > fragmentation and corresponding reliability issues don't kick in? RTMFP is a complete transport protocol that (while operating over UDP) handles fragmentation issues, varying guarantees for delivery reliability (none, partial, full) and ordering (in-order, as-received... even supporting in-order delivery of partially-reliable data), TCP-friendly congestion management with variable responses to congestion and cross-peer congestion management (so if A is receiving high-priority data from B then when C sends to A it backs off more strongly if loss is detected), IP address mobility support, encryption (where the entire session setup plus keying is several round-trips fewer than TCP+TLS), etc. Too many features to list here, essentially. > Media over TCP is necessary for traversing UDP blocking firewalls. If > the goal is to reduce load on the publisher by doing p2p, then > ideally, peers need to have all types of NAT/firewall traversal > mechanisms in their toolbox. However, as you pointed, there maybe > business reasons for not doing so -: One may also argue based on the > available data that there are too few UDP blocking firewalls, or too > few clients behind such firewalls so it does not really matter... RTMFP has nearly every NAT/firewall traversal mechanism it can while still running over UDP. (And no, it doesn't use STUN or ICE to do that, and while it achieves similar results it is superior for how it is used... RTMFP session establishment proceeds as rapidly as possible without any phases for doing things like gathering addresses. Because RTMFP is often used from Flash Player within the browser environment, spending time to use STUN to determine one's addresses before doing anything else would just add delay to the user experience. While STUN and ICE works well for something like a desktop phone that can spend a lot of time booting and then probing before it is time to make a call, it doesn't work well for something like instant call setup from within a web page. If you want to get an idea of what it can figure out about its environment, check out the test server I run in my garage: http://cc.rtmfp.net )
Because RTMFP is a complete transport protocol with things like retransmission and (selective) acknowledgment, it gets very confused if it is sent over a reliable channel like TCP where retransmission timers fire but then the data arrives anyway because the lower layer was doing the same thing. The Flash Player already has a much better protocol for moving media over TCP built-in, which is RTMP. And while RTMP only works for the client-server case, there are very few cases where peers are UDP-blocked and simultaneously able to accept incoming TCP connections, so finding a pairing where that's the case is so rare that we don't bother. > > > Are you saying that RTMFP has a mechanism of prioritizing audio/video > over file transfer? Yes. RTMFP manages a single congestion window for all flows and prioritizes media as requested. This means that if you are moving a large file to a peer at the same time you're doing VoIP with them, the VoIP can proceed without disruption while the file transfer uses all the remaining TCP-friendly bandwidth. There is also cross-peer management, as described above. > > > Ok, so the question really is can RTMP/RTMFP(pre/post groups) be run > together in a way that allows peer-to-peer media sessions where > possible but falls back to client server? Do you think the solution > will be seamless for RTM* protocol series? If I was building a > Skype-like system, I will need to ensure that session establishment > does not fail due to protocol or architecture artifacts. Another group at Adobe has developed what is now known as the "LiveCycle Collaboration Service" which, underneath all the interesting components, uses RTMP and RTMFP to do peer-to-peer when possible and client-server when not. So I believe that's an existence proof. Matthew Kaufman _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
