search

MonaSolutions / MonaServer

A lightweight RTMFP, RTMP, WebSocket and HTTP server!
http://monaserver.ovh
GNU General Public License v3.0
706 stars 212 forks source link

Group communication issue. #91

Open Adrian-S opened 2 years ago

Adrian-S commented 2 years ago

I'm trying to use RTMFP to have group communications using Air SDK, and for some reasons I am unabble to figure it out why connection from mobile phone app is not comunicating with desktop app.

Both desktop and mobile do connect, both connect to the group, or at least no new group is created. But no communication. Ocasionally I get "Missing port number in ´┐Ż´┐Ż" with the connection from the mobile app. Tested with both MonaServer 32bit and MonaServer2 64bit and we have a dedicated AWS server with MonaServer 1.2. No extra lua files, server streigth out of the box.

I'm trying to find the problem but I have no idea how to debug deeper and find the cause.

raresn commented 2 years ago

@thomasjammet any ideas here? Thank you!

thomasjammet commented 2 years ago

Hi!

I suspect a p2p connection issue, can you try the following link from both devices? https://demo.monaserver.ovh:4443/tests/p2pConnection.html

This tool uses WebRTC and try to connect 2 clients in P2P in the browser. Tell us the result and the output of "NAT type:", thanks.

raresn commented 2 years ago

Not 100% sure how we should run the test, but we added the STUNS servers indicated, and hit test: From desktop, on local LAN/internet connection, with the two STUNS servers: NAT type: standard Error: 408

From mobile phone #1 running on a standard 4g connection in incognito browser: NAT type: standard Error: test error. Failed to fetch

From phone #2 running on 4g NAT type: unknown

Adrian-S commented 2 years ago

With STUNS provided: PC1 + NetWork1: NAT type: port restricted PC2 + NetWork2: NAT type: standard PHONE + NetWork2 (wifi): NAT type: standard PHONE + 4G Mobile: NAT type: symmetric

At the moment of initial issue, tests were done between PC1 and Phone on 4G. Problem is still there on RTMFP + Air SDK.

thomasjammet commented 2 years ago

Thanks, @Adrian-S can you tell us if the test succeed between :

? Here is an example of test success : immagine Beware to always test with 2 peers, and then close the tabs to test again

Anyway the Phone + 4G with NAT symmetric is likely to not be able to connect in p2p, see http://en.wikipedia.org/wiki/UDP_hole_punching :

UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the well-known STUN server is restricted to receiving data from the well-known server, and therefore the NAT mapping the well-known server sees is not useful information to the endpoint.

It happens a lot with 4G and you should find a way to fallback to some other system.

Adrian-S commented 2 years ago

I've tested between PC1 and Phone on 4G multiple times. PC sometimes is standard sometimes is port restricted. Phone 4G sometimes is symmetric and sometimes is port restricted. Now WebRTC seams to be able to connect successful most of the time. The times it didn't could have been just strange cases.

Without STUN servers checked it fails with 408 error. Same if we use our MonaServer. I can only conclude Mona is not a STUN server that can be used in this test, or there are other issues.

RTMFP in AirSDK has something called serverChannel, that should help with peer discovery if they are not visible to each other. Also has something called peerToPeerDisabled for a Group, that indicates me that server should be acting as a relay between all peers. Maybe there is a setting in Mona to enable something, to allow connections even if p2p is not working. As I was saying, we got a dedicated AWS server for Mona and it's mostly doing nothing. We just need to send some text messages, so bandwidth would not be a problem.

thomasjammet commented 2 years ago

Ok thanks for the precision!

MonaServer has a internal STUN-like system on the same port as RTMFP which is working fine as long as MonaServer is located where you would like the STUN server to be. This means that MonaServer must be placed on an external position in order to find the correct public IPs of the clients. One common error is to put MonaServer on the same LAN than 1 of the clients, this will not work because MonaServer doesn't see the public address of this client.

For information the STUN-like process is done here : https://github.com/MonaSolutions/MonaServer2/blob/master/MonaCore/sources/RTMFP/RTMFPDecoder.cpp#L83-L148 I think it's not something documented by Adobe but it has been used a lot. If you want to debug and see the requests you can also enable debug logs : ./MonaTiny --log=7

raresn commented 2 years ago

@thomasjammet as a fallback system, anything you can recommend to use with AIRSDK that works on all platforms (ios, android, windows/mac)? We thought RTMFP to be exactly what we need...

raresn commented 2 years ago

Our Mona server is hosted on AWS. Our goal is to use it (reliably) to communicate that the a mobile app we developed needs to pull data from another server. So all users that are connected in a netgroup, to receive a message "PULL", and they will all do a load. So we don't care about P2P, we need all this to happen through the server. But we need to reliably connect the user to the server and make sure everyone gets the message from the server.

thomasjammet commented 2 years ago

Hi, sorry for the late answer. If you don't need to support a huge number of clients you can simply use a permanent WebSocket connection to a WebSocket server, this is a protocol supported everywhere and using the common HTTP port (80 or 443 for HTTPS).