Android Question [UDP] i want to query ip 151.66.30.122 and not local ip

ivanomonti · Mar 23, 2023

UDPSocket

I need to query my server (self-built) not locally but through an external IP, I set Port Forwarding but now I wonder how the client can point to a non-local IP but (example) > IP 151.66.30.122

Erel · Mar 23, 2023

If your server doesn't have a static ip address assigned by the ISP then you can use a dynamic ddns service such as https://www.noip.com/

cklester · Mar 23, 2023

ivanomonti said:
UDPSocket

I need to query my server (self-built) not locally but through an external IP, I set Port Forwarding but now I wonder how the client can point to a non-local IP but (example) > IP 151.66.30.122

You can get your IP address here: What Is My IP Address?

Point the client to the IPv4 address shown on that page.

Also, what Erel said...

Star-Dust · Mar 23, 2023

Note that both must have a public IP.

If you communicate between PC and mobile it is possible that the mobile device does not have a public IP.
Or if one (or both) devices are inside a LAN/wifi you have to enter routing policies in the router to get the packet to the right device inside the network

ivanomonti · Mar 23, 2023

Erel said:
Se il tuo server non ha un indirizzo IP statico assegnato dall'ISP, puoi utilizzare un servizio ddns dinamico come https://www.noip.com/

@Erel

Erel said:
If your server doesn't have a static ip address assigned by the ISP then you can use a dynamic ddns service such as https://www.noip.com/

@Erel I already use noip and the phone reaches the local pc very well but vice versa not

ivanomonti · Mar 23, 2023

Star-Dust said:
Note that both must have a public IP.

If you communicate between PC and mobile it is possible that the mobile device does not have a public IP.
Or if one (or both) devices are inside a LAN/wifi you have to enter routing policies in the router to get the packet to the right device inside the network

@Star-Dust in reality this is not the case, because the ports do their job, locally in fact I have no problems everything goes smoothly, unlike remotely from phone to pc it arrives and from pc to phone it doesn't

questa immagine fa vedere chiaramente che il server sul mio pc e instradato con noip funziona

NOIP DUC

B4J server

ivanomonti · Mar 23, 2023

bene sembra funzionare a meraviglia con ip remoto a locale & locale su remoto, tempi sono accettabili 1 max 2 secondi per la risposta dal mio pc.

Vediamo di fare il giro dell'oca

ip192.168.0.1 (locale) viene trasformato in
ip 151.66.30.22 remoto

Porte 51015 / 51099
Port Forwarding sul mio router

Telefono con IP inoltra la domanda > pc ascota e recupera la domanda > pc pone la domanda a chatgpt > chatgpt risponde al pc > pc filtra la risposta > pc invia la risposta al telefono con IP > telefonino mostra la risposta.

1/2 secondi

Star-Dust · Mar 23, 2023

ivanomonti said:
unlike remotely from phone to pc it arrives and from pc to phone it doesn't

Star-Dust said:
Note that both must have a public IP.

If you communicate between PC and mobile it is possible that the mobile device does not have a public IP.

This means that the mobile device reaches the PC that has a public IP and not vice versa, and indeed you can't cast from pc to mobile,

ivanomonti · Mar 23, 2023

Star-Dust said:
This means that the mobile device reaches the PC that has a public IP and not vice versa, and indeed you can't cast from pc to mobile,

now for example it's working well, in this image I put an alert and I see that everything is arriving correctly. 1/2 second to wait

phone > pc

pc > phone

Star-Dust · Mar 23, 2023

Because you are in local network 192.168.1.143

However it was just a piece of advice, continue your work surely you will find answers to your questions

ivanomonti · Mar 24, 2023

Star-Dust said:
Perché sei nella rete locale 192.168.1.143

Comunque era solo un consiglio, continua il tuo lavoro sicuramente troverai risposte alle tue domande

Non credo che troverò una risposta in UDP, non ho esperienza e non ho testa in questo periodo e non mi accorgo nemmeno come hai detto che sono locale.

Mi sento proprio uno stronzo a disturbare la rete, perdere credibilità e sembrare uno stronzo.

Sto cercando di studiare MQTT sperando di capirlo anche perchè negli esempi erel trovo errori da cui non so da dove partire e non ho un supporto che mi possa aiutare

Star-Dust said:
Because you are in local network 192.168.1.143

However it was just a piece of advice, continue your work surely you will find answers to your questions

I don't think I'll find an answer in UDP, I have no experience and no head in this period and I don't even notice as you mentioned that I'm local.

I feel quite an asshole to disturb the network, lose credibility and look like an asshole.

I'm trying to study MQTT hoping to understand it also because in the erel examples I find errors that I don't know where to start from and I don't have a support that can help me

teddybear · Mar 24, 2023

ivanomonti said:
I don't think I'll find an answer in UDP, I have no experience and no head in this period and I don't even notice as you mentioned that I'm local.

I feel quite an asshole to disturb the network, lose credibility and look like an asshole.

I'm trying to study MQTT hoping to understand it also because in the erel examples I find errors that I don't know where to start from and I don't have a support that can help me

Don't be discouraged. if you just would like to study MQTT , local network is enough, also there are a few of free public brokers for testing on internet. you will get any help , beacuse the Forums is your support.

OliverA · Mar 24, 2023

Your phone's IP address of 172.20.10.3 falls within the private IP range of 172.16.0.0 through 172.31.255.255. Your phone provider is using private IPs instead of public IPs, just like your devices are at home that are connected to your home network. Your routers sees this private IP when your PC is trying to communicate with your phone and drops the packet, since your network has no device with IP 172.20.10.3. In your case MQTT would be one of the solutions to use for your problem. For a more "real time" feel, you may also want to investigate WebSockets, where your phone would do a WebSocket connection to an application on your PC.

ivanomonti · Mar 24, 2023

OliverA said:
Your phone's IP address of 172.20.10.3 falls within the private IP range of 172.16.0.0 through 172.31.255.255. Your phone provider is using private IPs instead of public IPs, just like your devices are at home that are connected to your home network. Your routers sees this private IP when your PC is trying to communicate with your phone and drops the packet, since your network has no device with IP 172.20.10.3. In your case MQTT would be one of the solutions to use for your problem. For a more "real time" feel, you may also want to investigate WebSockets, where your phone would do a WebSocket connection to an application on your PC.

you have an example

MicroDrie · Mar 27, 2023

I'm afraid there isn't a simple short answer. Let me first summarize the specific network behavior for the private network address space, which is a network address in the following three network addresses:

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

A private address space is a network address which can’t connect to the public internet because a router doesn’t route those private addresses. However you can take additional measures in the router like port forwarding to overcome this restriction for a specific address or add an additional rotation rule in the routing table of a router.

The difference between the “light” session less UDP protocol and TCP is that UDP doesn’t give a guarantee for a successful delivery of a UDP packet and there is nothing to indicate a failure or succesfull delivery of a UDP packet! If a successful delivery is needed your must add additional programming to overcome this protocol behavior. If a device use the TCP protocol to connect to a device on an other network segment, the router add the sending network address in a session table for the return traffic.

Special network addresses:

The highest network address of a network segment is used for the so-called multi cast address. All devices on a network segment will respond when this address is used.

Then there is a so-called loopback address 127.0.0.1, but you may see it under the name "localhost." You can use it to test if the network stack is correctly working and the Windows Operating System (OS) allow loop back any protocol for this network address. This is why using this address doesn’t needs an entry in the firewall filter list for in and outgoing traffic.

In the routing table the address 0.0.0.0 is used as the destination for all not know network addresses.

Two network device can freely communicate with each other as long that they are on the same network segment without the help of a routing network device. The range of included addresses of a network segment depends on the used network mask or prefix for a network segment. You can limit a segment to use 255 addresses by a network mask of 255.255.255.0.

Specially the correct use of the sub-net mask is always the hardest thing in every network course, because it is easy to make a miss configuration which result in impossible communication between two or more devices into the network segment.

Networks devices can only communicate without conflicts if all devices has unique network addresses. The purpose of DHCP (Dynamic Host Configuration Protocol) is to provides quick, automatic, and central management for the distribution of unique IP addresses for a network segment to overcome the need of manual fix network addresses.

Every network device has a unique 48-bit hardware Media Access Control (MAC) Address. It is possible to use the unique MAC address of the network card (known as a Network Interface Card) in the DHCP server (in the router) to give that unique MAC address a fix DHCP network number. Or, as Erel mentioned to use the dynamic ddns service such as https://www.noip.com/ to overcome the need of manual fix network addresses.

A router connected to the public internet has on the internet site an interface which is accessible from all addresses on the internet. Behind the router are the non-routable private network addresses. Port-forwarding is a technique by adding a specific port address on the public internet interface which route the traffic to a specific port and a local specific private network address.

When we look to this network knowledge to the original question from Ivano Angelo Monti

UDPSocket

I need to query my server (self-built) not locally but through an external IP, I set Port Forwarding but now I wonder how the client can point to a non-local IP but (example) > IP 151.66.30.122

It looks that the sessionless UDP procol is used, or simple said “through it over the wall and hopefully the server picks it up, through nothing backs over the wall”.

If Ivano Angelo Monti wants to receive somethings back from the server there are two problems by the use of the UDP protocol. First the server knows only the public interface of Ivano Angelo Monti internet router, but not the local specific private network address from a device on his private network. And with the default use of DHCP on his private network, the device on his network can have any network address, so this complicates the use of port forwarding after a device receive a new and other address of the device on Ivano Angelo Monti prive network.

In this case the use of port-forwarding which can be simple “through something through the hole in the wall and it will come to the right device” doesn’t work when you do not use fix addresses. Or it simple put “it works till the next reboot of the device and / or router”.

So considering the foregoing, the answer is that UDP can be used as a simple way to send something to a central server without reporting back to the sending device. If something needs to be sent back, it is more convenient to use a TCP session to overcome a complex configuration of the network router.

ivanomonti · Mar 27, 2023

MicroDrie said:
I'm afraid there isn't a simple short answer. Let me first summarize the specific network behavior for the private network address space, which is a network address in the following three network addresses:

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

A private address space is a network address which can’t connect to the public internet because a router doesn’t route those private addresses. However you can take additional measures in the router like port forwarding to overcome this restriction for a specific address or add an additional rotation rule in the routing table of a router.

The difference between the “light” session less UDP protocol and TCP is that UDP doesn’t give a guarantee for a successful delivery of a UDP packet and there is nothing to indicate a failure or succesfull delivery of a UDP packet! If a successful delivery is needed your must add additional programming to overcome this protocol behavior. If a device use the TCP protocol to connect to a device on an other network segment, the router add the sending network address in a session table for the return traffic.

Special network addresses:

The highest network address of a network segment is used for the so-called multi cast address. All devices on a network segment will respond when this address is used.

Poi c'è un cosiddetto indirizzo di loopback 127.0.0.1, ma potresti vederlo sotto il nome "localhost". Puoi usarlo per verificare se lo stack di rete funziona correttamente e il sistema operativo Windows (OS) consente il loopback di qualsiasi protocollo per questo indirizzo di rete. Questo è il motivo per cui l'utilizzo di questo indirizzo non richiede una voce nell'elenco dei filtri del firewall per il traffico in entrata e in uscita.

Nella tabella di routing l'indirizzo 0.0.0.0 viene utilizzato come destinazione per tutti gli indirizzi di rete sconosciuti.

Due dispositivi di rete possono comunicare liberamente tra loro purché si trovino sullo stesso segmento di rete senza l'ausilio di un dispositivo di rete di routing. L'intervallo di indirizzi inclusi di un segmento di rete dipende dalla maschera di rete utilizzata o dal prefisso per un segmento di rete. È possibile limitare un segmento all'utilizzo di 255 indirizzi mediante una maschera di rete di 255.255.255.0.

Specialmente l'uso corretto della maschera di sottorete è sempre la cosa più difficile in ogni percorso di rete, perché è facile fare una configurazione errata che si traduce in una comunicazione impossibile tra due o più dispositivi nel segmento di rete.

I dispositivi di rete possono comunicare senza conflitti solo se tutti i dispositivi hanno indirizzi di rete univoci. Lo scopo di DHCP (Dynamic Host Configuration Protocol) è fornire una gestione rapida, automatica e centralizzata per la distribuzione di indirizzi IP univoci per un segmento di rete per superare la necessità di correggere manualmente gli indirizzi di rete.

Ogni dispositivo di rete ha un indirizzo MAC (Media Access Control) hardware univoco a 48 bit. È possibile utilizzare l'indirizzo MAC univoco della scheda di rete (noto come scheda di interfaccia di rete) nel server DHCP (nel router) per assegnare a quell'indirizzo MAC univoco un numero di rete DHCP fisso. Oppure, come ha detto Erel, utilizzare il servizio ddns dinamico come https://www.noip.com/ per superare la necessità di correggere manualmente gli indirizzi di rete.

Un router connesso alla rete internet pubblica ha sul sito internet un'interfaccia accessibile da tutti gli indirizzi su internet. Dietro il router ci sono gli indirizzi di rete privata non instradabili. Il port forwarding è una tecnica che aggiunge un indirizzo di porta specifico sull'interfaccia Internet pubblica che instrada il traffico verso una porta specifica e un indirizzo di rete privata specifico locale.

Quando guardiamo a questa conoscenza della rete alla domanda originale di Ivano Angelo Monti

Sembra che venga utilizzato il protocollo UDP senza sessione, o semplicemente detto "attraverso di esso oltre il muro e si spera che il server lo raccolga, attraverso il nulla oltre il muro".

Se Ivano Angelo Monti vuole ricevere qualcosa dal server ci sono due problemi con l'uso del protocollo UDP. Innanzitutto il server conosce solo l'interfaccia pubblica del router Internet di Ivano Angelo Monti, ma non l'indirizzo di rete privata specifica locale di un dispositivo sulla sua rete privata. E con l'uso predefinito di DHCP sulla sua rete privata, il dispositivo sulla sua rete può avere qualsiasi indirizzo di rete, quindi questo complica l'uso del port forwarding dopo che un dispositivo riceve un nuovo e altro indirizzo del dispositivo sulla rete privata Ivano Angelo Monti.

In questo caso l'uso del port forwarding che può essere semplice “attraverso qualcosa attraverso il buco nel muro e arriverà al dispositivo giusto” non funziona quando non si usano indirizzi fissi. O semplicemente “funziona fino al prossimo riavvio del dispositivo e/o del router”.

Quindi, considerando quanto sopra, la risposta è che UDP può essere utilizzato come un modo semplice per inviare qualcosa a un server centrale senza riferire al dispositivo di invio. Se qualcosa deve essere rispedito, è più conveniente utilizzare una sessione TCP per superare una complessa configurazione del router di rete.

Thank 1000

ddefrain · Mar 27, 2023

ivanomonti said:
UDPSocket

I need to query my server (self-built) not locally but through an external IP, I set Port Forwarding but now I wonder how the client can point to a non-local IP but (example) > IP 151.66.30.122

Check if your ISP Provider is blocking ports

Star-Dust · Mar 29, 2023

ivanomonti said:
Non credo che troverò una risposta in UDP, non ho esperienza e non ho testa in questo periodo e non mi accorgo nemmeno come hai detto che sono locale.

Mi sento proprio uno stronzo a disturbare la rete, perdere credibilità e sembrare uno stronzo.

Sto cercando di studiare MQTT sperando di capirlo anche perchè negli esempi erel trovo errori da cui non so da dove partire e non ho un supporto che mi possa aiutare

I don't think I'll find an answer in UDP, I have no experience and no head in this period and I don't even notice as you mentioned that I'm local.

I feel quite an asshole to disturb the network, lose credibility and look like an asshole.

I'm trying to study MQTT hoping to understand it also because in the erel examples I find errors that I don't know where to start from and I don't have a support that can help me

If you allow me, the problem is that you don't read the answers carefully, sometimes you ignore them completely or you even criticize them with observations that aren't always relevant to the problem. If you ask questions, you must be willing to accept the suggestions or at least consider them carefully.

I'm adding some observations based on all the threads you've entered for your app so I'm only responding to one.

It is not true that with UDP it is not possible to be sure that the packet has reached its destination, but more correctly the protocol does not provide for a confirmation that can be obtained in any other way
It has been suggested that you use MQTT to broadcast messages without having to install a server on your PC. This is a great solution and simple to use.
If you use PC as server you can also try sockets as per Erel example (here https://www.b4x.com/android/forum/threads/b4x-asyncstreams-tutorial.7669/)
Using a poll with a timer that consults a MySQL server for devices to communicate with each other is always a bad idea. You have been told several times on the Italian forum to avoid polling. As mentioned above when you take into consideration the advice given to you otherwise there is no use asking
Lastly, I want to point out that lucaMs also suggested the WebSock for the app you want to create, this too is an excellent solution and would solve many problems.

I am sure that by following the many great suggestions you have received in the threads you have opened you will be able to complete your work

ivanomonti · Mar 29, 2023

1) mi sono espresso male nel post, si confermo il protocollo UDP non consegna una conferma.
2) vero che mi è stato detto di provare MQTT, anche Erel me lo ha suggerito, ma non riesco a capire come usarlo. **
3) si userò un pc come server e mysql, visto che le domande e risposte le devo memorizzare.
4) non uso timer per un sondaggio ma leggo le domande non evase e dando le risposte alle domande (scrivendole su database mysql), il client a sua volta andrà a leggere le risposte
5) verissimo e lo sto studiando **

** @Star-Dust a volte non basta dire usa o prova quello, a volte bisogna dare qualche info in più (e so che non è sempre possibile) altrimenti si rischia di fare effetto contrario per poi escludere la persona. io ti ringrazio per questi tuoi suggerimenti e vedrò cmq di evitare di far domande inutili e pubblicare il mio entusiasmo.

---------

1) I expressed myself badly in the post, yes I confirm the UDP protocol does not deliver a confirmation.
2) true I was told to try MQTT, Erel suggested it too, but I can't figure out how to use it. **
3) I will use a pc as server and mysql, since I have to memorize the questions and answers.
4) I don't use a timer for a survey but I read the unanswered questions and by giving the answers to the questions (writing them on the mysql database), the client in turn will read the answers
5) very true and I'm studying it **

** @Star-Dust sometimes it's not enough to say use or try that, sometimes you have to give some more info (and I know it's not always possible) otherwise you risk having the opposite effect and then excluding the person. I thank you for your suggestions and I'll try to avoid asking useless questions and publish my enthusiasm.

Star-Dust · Mar 29, 2023

In the translation you lost something, "Polling" is a technical term that indicates a repeated request after time expires. This is bad practice. That would be what you do with the timer. It's not wrong to use MySQL, but to do a keep repeating read request to check for new queries.

However, it is a speech that is difficult to explain to you if you do not know the technical terms. But if you want to continue on this path, that's fine with me.

Questions are not useless, but sometimes you have to know how to wait for them to provide you with the extra information you ask for, each of us has our own times and commitments. But sometimes you can do it first by looking at the examples. There are many mqtt

I repeat the concept: if you want suggestions we will give them to you and they will be useful if you then take them into consideration

Android Question [UDP] i want to query ip 151.66.30.122 and not local ip

Expert

B4X founder

Well-Known Member

Expert

Expert

Expert

Expert

Expert

Expert

Expert

Expert

Well-Known Member

Expert

Expert

Well-Known Member

Expert

Member

Expert

Expert

Expert

Similar Threads

Privacy & Transparency

Privacy & Transparency