According to the article quoted below, if we want to use Cirrus for RTMFP connection it should stay connected for the whole communication period.
Cirrus service
Flash Player instances must connect to the Cirrus service (using rtmfp://p2p.rtmfp.net) in order to communicate with one another. Cirrus is a hosted rendezvous service that helps Flash Player instances contact one another even if they are located behind NATs. Although connecting to Cirrus service is very similar to connecting to Flash Media Server, Cirrus does not provide any of the typical Flash Media Server features (media relay, shared objects, remoting, etc.). Flash Player endpoints must stay connected to Cirrus during the entire time of communication . In order to access Cirrus, you will need a developer key that is generated when you create your Adobe Developer ID.
http://www.adobe.com/devnet/flashplayer/articles/rtmfp_cirrus_app.html
And I wonder why do we need to keep the server communication after the first NAT traversing hand shake?
What part does it take when a P2P connection between the clients is done?
Imagine you have various clients in a NetGroup and then one client suddenly disconnects. Due to the stateless nature of UDP, the other clients don't recognize the disconnect. This event is being handled and dispatched to the other clients by Cirrus.
Furthermore, Cirrus handles the translation of peer IDs to network addresses. This must be done in the period in which clients are connected.
Related
I'm working in a project where we need to connect clients to devices behind LAN networks.
Brief description: there are "devices" connected, in a home for example, under a LAN created by a router. These devices create a full webserver, operating under linux, and using nodejs as the backend implementation language. They also have access to Internet, through the public IP of the router. On the other side, there are clients which can choose to which device to connect to.
The goal is to connect the clients with the webServer created by any device.
Up to now, my idea is to try to implement something similar to how TeamViewer works. As I understand, Teamviewer has a central server, which the agents connect to. When an agent connects to the central server, this one gets hold of the TCP connection, keeping it alive. When another client wants to access to the first client, the server bypasses both TCP connections. That way the server acts like a proxy, where it additionally routes the TCP connections. This also allows to connect to clients under LAN or firewalls (because the connections are created always from the clients).
If this is correct, what I would like to implement is a central server, in nodejs as well, which manages a pool of socket connections coming from the different active devices, and when a client wants to connect to one specific device, the server bypasses the incoming TCP connection of the client with the already existing connection of the device.
What I first would like to know is if this is possible in nodejs. My idea is to keep the device connections alive, so clients can inmediately connect to them, creating some sort of pool of device connections.
If implemented in C, I guess I could get hold of the socket descriptor, keeping it alive, and bypassing it to the incoming client request. But in nodejs I can't seem to find any modules that manage TCP connections.
Are there any high level npm packages which do this function? Else, is it possible to use lower level modules (like net) which have those functionalities.
Ideally I would like to implement it with high level modules (express), but if it's not possible, I could always rewrite the server using low level modules.
Thanks in advance
As we all know, HTTPS is a way to protect against session hijacking.
Suppose this isn't an option for some application. Further suppose, users connect to the web-application using a strongly encrypted (WPA2) wifi network.
Fact: WPA2 protects against third parties, which didn't connect correctly to the wifi network.
But does WPA2 additionally protected each legitimate user against each other legitimate user? Does each legitimate user has a securely isolated channel to the wifi router?
Or does the wifi router works more like a hub: If the wifi router needs to send data to a wifi client, it broadcasts it to all clients - so that each client can read the data?
Speaking of web application programming: Do we need to use HTTPS in a
WPA2 protected wifi network to protect each wifi client against each
other wifi client?
In Wi-Fi, as the transmission medium is the air, every STA could intercept data from others STA. So, for this point, you can compare a Wi-Fi network to a hub.
In fact, the 802.11 stack take care of the PHY and the MAC/LLC layers.
Moreover, the WPA/WPA2 encryption is just here to protect foreign STA to read your Wi-Fi network frames.
It's very easy to test, use wireshark with two STAs on the same AP. You should be able to see frames form the other STA.
So if you want to protect a web application on a network which use Wi-Fi (and/or hub but not only), the use of HTTPS is strongly recommended.
I want to create peer-to-peer connections between 2 nodejs client.
using websocket (dnode)
here is the limit:
nodejs client run at 2 pc which is in different network.
they don't have static ip (192.168.1.100 && 192.168.2.200) behind NAT or firewalls
no permission to change the mapping of router.
has only static web server in public network. (can change the file by human)
can install application at pc (win)
is it possible? thanks
May be you can use PeerJS to achieve your objectives.
PeerJS simplifies WebRTC peer-to-peer data, video, and audio calls.
PeerJS wraps the browser's WebRTC implementation to provide a complete, configurable, and easy-to-use peer-to-peer connection API. Equipped with nothing but an ID, a peer can create a P2P data or media stream connection to a remote peer.
Also to broker connections, PeerJS connects to a PeerServer. Note that no peer-to-peer data goes through the server; The server acts only as a connection broker.
If by peer to peer connection, you mean direct connection between the peers (i.e., not via a server) then yes it is probably possible in theory in most cases. But I have never seen someone who has implemented the solution.
You would need to implement a NAT hole punching system for TCP connections (they are not always 100% successful because of technical constraints which can't be solved at the software layer). Then, you'd just need to implement the websocket protocol on top of this tcp connection.
If by peer to peer connection, your are ok that communication passes via a central server (with a public address), then yes it is possible too. Both peers just need to connect to the central server, and it should just transfert the traffic between both peer.
I want to clear of my basics before I Jump into more complicated matter of bluetooth. I have following basic question.
If there is two bluetooth devices(A phone and a bluetooth display). Is it that bluetooth connection is initiated only by the phone.
Suppose there would be lot of bluetooth communication happening from a phone to bluetooth display.Both devices can send messages to any other devices at any time. What is usual design approach of communication. Is it that the phone creates a Socket Connection to the bluetooth display through RFCOMM first time by sending a connect request to the Bluetooth device and this connection is maintained all the time or for every message the Socket connection is made and then socket is closed, after that again reopened and closed for next message.
If the connection is opened till the devices are in nearby range what are the consequences.
What is normal way of communication in case of phone and headset.
Can I get any reference so that i can get some knowledge about that.
1) In general, bluetooth connections can be initiated by either device. For example, with a phone and computer, you could start a connection from either side. With a phone and a display or headset, there may be no input interface on one device, so you would initiate connections from the phone. Devices can also auto-negotiate role switches such that they swap master/slave roles.
2) If you have continuous data to exchange, or require low latency, the connection would typically be left up. If you only have rare messages to exchange, tearing down the connection would save power because the devices are maintaining the connection synchronization by exchanging null packets.
3) You can't maintain a connection with devices out of range. If they can't communicate for some timeout period (on the order of seconds) then they lose sync and kill the connection.
4) Note that phone/headset are not using RFCOMM connections, rather the HSP (headset profile). Connections for isochronous voice data are inherently different than a sporadic data connection like RFCOMM.
5) A good way to see how "real" devices are communicating is to use tools like hcidump, as part of the linux blueZ stack. This lets you fully sniff the protocol messages that happen as you connect devices.
Please let me know what architecture do VoIP applications use, P2P or Client-Server?
Thank you.
Some of each in general. There are three protocols involved, usually. One of them, for example SIP, is used to establish the connection. you need a server for that because someone has to establish the original connection; that means advertising availability and such. The other two are essentially always RTP and RTCP -- "real time protocol" and "real time control protocol", and those are better P2P, because you want fast transmission with no intermediate bottleneck.
There's a nice article on the whole discussion here.
There's usually some kind of "presense server": devices register ("I exist here!") and calls are established via the server (when you say "I want to connect to device (555) 555-1234" that connection request is routed via presence servers).
After the call is established and the real-time voice/media is streaming, that traffic is usually peer-to-peer (bypassing any central server), except if there's a complication like both devices being behind firewalls.