I want to know how can it benefit my application if I have the version that have IP multicast. Please explain to me in simple terms. Thanks
Adobe Media Server supports IP multicast streaming and recording for live video to Flash Player 10.1 or later. Multicast is a highly optimized method to deliver high-quality video to a very large audience with virtually no impact on the server as demand increases.
Adobe Media Server can generate a multicast broadcast from any live RTMP stream or a linear stream from a server-side playlist. Flash Player 10.1 and later clients do not need a server connection to receive the stream. Multicast is very useful for large-scale broadcasts within enterprise networks.
Video players developed with OSMF will have full support for IP multicast.
Source-specific multicast (SSM) lets you generate and consume both SSM and any-source multicast (ASM), enabling stream replication, server-side recording, or rebroadcast over separate multicast channels or RTMFP groups. SSM support reduces the demand on the network resources while also improving the security of the streams.
Related
I have a surveillance Camera and i want to stream the live feed to multiple clients in the same network using WebRTC. To save compute resource and bandwidth requirement i want to do multicasting on WebRTC feed. Is this possible?
WebRTC doesn't support multicast. You might want to look into tools like webtorrent.
I am planning on a small project and need help regarding its feasibility.
I have a few wireless mobile devices (could be phones and laptops) which periodically broadcast packets and also each device listens for other broadcasts. Any device in range should receive the broadcasted data (no need to reply or ackwnoledge).
To perform this can I just send UDP packets with address 255.255.255.255, I heard this was deprecated. If so how do I achieve this? There is no underlying network topology so I cannot rely on multicast or is there a way?
If there are 100 such devices, all in wireless range, each 1 performing a periodic broadcast and receive, will it work? will there be too many collisions ? and become infeasible. Each device receiving 70% of the packets is a good performance according to me.
Thank You
Unfortunately, it doesn't work this way.
You won't be able to send IP-layer broadcast packets until you have associated with an access point. Once association has been made, only devices associated with the same AP (and other devices bridged to the IP over its wired interface) will see your broadcasts. The same goes for layer 2 broadcasts as well.
What you need is to get at a lower layer. Unfortunately, each WiFi adapter has different methods for doing this, and for many, it isn't even possible. I'm afraid what you are attempting will not work.
I am designing a system which has multiple small embedded systems hosts communicating in a LAN. UDP multicast fits nicely for my purpose.
But I am worried about multicast support in commonplace routers. I need to deploy the system to normal households equipped with a Wifi router, so I could encounter any kind of routers. I will use UDP broadcast if multicast will be more trouble than benefit.
To decide, I am thankful for any data or experience on multicast support in today's commonplace routers:
Do all consumer routers sold today support multicast reasonably? Limitation to LAN is not an issue for me, I do not need multicast across the Internet.
How about older routers?
Are there any big issues in commonplace multicast implementations I need to be aware of (e.g. packet drops, configuration issues, etc.)?
Are you talking switches or routers? In a consumer setting I suspect switches. My experience is that they all support multicast, though not at wire speed. Also the cheap ones tend to broadcast any multicast traffic to all ports (no IGMP snooping). Packet loss is definitely something you need to deal with, it can and will happen even on 'professional' networking gear.
Edit: as long as you are in switched network, you typically don't need to configure anything.
In many scenarios the equipment either does not support IGMP spoofing, or it is off by default. There are two problems:
Any wireless interface can be saturated by the traffic.
Poorly configured units may inadvertently route traffic out the default gateway stalling legitimate traffic.
In either case, you will have your equipment discarded as the cost of investigation will almost certainly outweigh the benefit received.
If your traffic has a limited rate and you are not concerned about the WiFi impact, you could use the local broadcast address to ensure delivery to recipients, without impacting on the routed communications.
You could install a discovery mechanism into your nodes it may be worthwhile to implement a unicast overlay to ensure that traffic does not have inadvertent impact.
A single larger group of customers with some non-compliant devices requesting support will swamp any costs associated with development or additional traffic caused by not implementing true multicasting.
In worst case scenarios, when the routers don't allow multicast traffic, I would encapsulate the multicast packets into a unicast IP address. This way the routers would handle them as normal unicast data. You might want to check mrouted .
Good luck
Is it possible to communicate with RTMFP from serverside without flash server?
Thanks ;)
Presumably you just need to communicate with the Flash player so that's not related to RTMFP and is easily accomplished.. Did I misunderstand?
RTMFP is a p2p communication method, but you need to have a server in order to exchange the ID of the p2p participants.
There is a GPS device which can send data to IP:Port. I have a website hosted on IP 1.2.3.4
Can I send GPS data from the device to that website? 1.2.3.4:8080? How I will retrieve the data?
This is the device
http://cgi.ebay.com/GSM-GPRS-GPS-Vehicle-Car-Tracking-System-Tracker-Device-/270683202099?pt=AU_Car_Parts_Accessories&hash=item3f05f9e233
Maybe this should be a comment...
To be honest we can't answer that question the device will most likely use its own data format(s) so the service that receives from it will have to implement those. Additionally the device might not support web protocols, it could use raw TCP sockets for example, so you may have to implement a listener service that adheres to those protocols. In fact it looks like the device uses GSM (a mobile telephony standard), so using a web site to receive the data is definately off the cards unless you have a GSM proxy service sitting between the device and the web server.
Assuming that you are allowed to implement your own service it follows that the documentation will include the necessary details and if you are lucky a full SDK that you can use.