Does Flash10 + p2p really work?

后端 未结 4 2074
悲&欢浪女
悲&欢浪女 2020-12-13 17:03

I\'ve been googling around and I still can\'t get it. Some people say: here you go, just use it. Others claim it has certain restrictions that does not allow you to use p2p

相关标签:
4条回答
  • 2020-12-13 17:24

    Hmmm... that's an interesting proposition, only keep the downloaded file in Flash's memory. I think it's certainly possible, but probably slow and you would be capped at a few hundred megabytes.

    EDIT: It's NOT possible because you cannot listen to ports using just Flash, the browser does not have that type of capability.

    0 讨论(0)
  • 2020-12-13 17:26

    All this information is out of date now.

    0 讨论(0)
  • 2020-12-13 17:33

    Flash doesn't allow you to listen on a socket for incoming connections. This would make it really difficult to work with existing torrents. Given the security issues around this, I don't see it happening.

    Adobe, however, has started their own version of a P2P system called Stratus. You can read about that here http://labs.adobe.com/technologies/stratus/

    0 讨论(0)
  • 2020-12-13 17:35

    The answer is pretty much no ... well, it's just no, to be honest.
    @drudru pointed out the right technology for flash p2p, i.e. stratus.

    Flash p2p is based on RTMFP, which is built upon UDP. Actually, flash does bind a port, but this comes from the internals. There is no API to do that manually.

    RTMFP basically allows two things:

    1. UDP streaming (unreliable, but fast) for video and audio. From flash side you can only publish your camera and microphone stream. From the server, almost anything.
    2. Doing remote calls to the other endpoint of the p2p connection. This can be used to transfer data. This communication is secured, i.e. package order and integrity is maintained by the flash player.

    The p2p is based on NAT punchthroughs. Stratus itself is the introduction server. Also, for security purpose, a p2p connection also means, both clients have to have an idling TCP (if I remember correctly) connection to the server. I guess, a bit of data is transmitted of course, but not the payload.

    However, the torrent protocol is very different from this. Therefore, this is not an option. You could build an equivalent protocol on top of RTMFP, reverseengineering the stratus service (or wait until it's open sourced). This could of course also be used by non-flash clients. But again, you would not be able to watch the transmitted data as a video, since you will get is as a param to some call to the client of your NetStream, probably a ByteArray. And you cannot play back ByteArrays. You could write non flash clients, that publish videos as a stream, but that would be far from what you wanted, I guess.

    If you really want to do anything like that, you need Java. You can sign Java applets, and if user accepts the certificate, they have practically unrestricted access, e.g. you could bind ports. Since Java can do UDP, you could have a Java applet, that does the torrenting (maybe just use the Vuze codebase) and if you really want to display it in flash (which in turn requires flv), then you could mime a local "Flash Media Server" and publish the video on localhost:someport. But really, the flash bit seems ridiculously complicated and useless to me. Rather try playing back with Java, which hopefully has an option to do so natively.

    0 讨论(0)
提交回复
热议问题