I tested RC5-RPC-Chat-Demo, and it worked very well on my computer. So I tried to test it on two computers in a home WIFI, one as an RPC server and one as an RPC client. I started the RPC server first, and then started the RPC client (chat client). In the chatclient login window, UDP could detect the IP address of the RPC server (the HostName TextBox was green), but when the login button was clicked, the system popped up the following error message. I would like to know what might be the reason for this error? Do I need to setup RPCServer.ini? Thanks.
Last edited by dreammanor; Apr 18th, 2018 at 11:06 AM.
Re: RPC-Chat-Demo: Lan-Network (WIFI) connection test
We'd need to know more about your network.
It sounds like this network is not passing UDP broadcasts between the two machines. Most network devices will not forward broadcasts through routers. Many home "combo" devices (switch, router, access point) do not have "logically" treat the WiFi access point as part of the same network segment as those on the Ethernet switch.
It only gets more complicated if you are using discrete devices instead of an integrated unit. And it is probably impossible if you have done something silly like totem-poled two routers.
There really is no programming question here at all unless you are willing to look at alternatives such as a TCP server that both clients connect to. Even that may be problematic if you have indeed wired two private-network NAT routers in a totem-pole configuration.
But I admit I am guessing about what the undocumented library (or libraries?) are doing.
Re: RPC-Chat-Demo: Lan-Network (WIFI) connection test
I can help with that. Basically for years I had the same problem. First of all (if you haven't already), you need to port forward your port number on your router that the server is running on. You can access your router settings using a particular ip address, and typically admin is the user name and password is the password. Next, on your router settings, you must enable DMZ to allow other computers from the outside world to access your computer. Then on your Windows machine, you need to give special permissions to your firewall to both the port number, and the server app to Incoming and Outgoing. Once you have all that, test to see if its accessible now with PFPortChecker.exe. If its successful, you are good to go. Just be sure your server is using the local ip and your client apps are using an external ip address. This is how I got my chat program going with the server made in C++ and my client apps on Android
Re: RPC-Chat-Demo: Lan-Network (WIFI) connection test
Originally Posted by dilettante
We'd need to know more about your network.
It sounds like this network is not passing UDP broadcasts between the two machines. Most network devices will not forward broadcasts through routers. Many home "combo" devices (switch, router, access point) do not have "logically" treat the WiFi access point as part of the same network segment as those on the Ethernet switch.
It only gets more complicated if you are using discrete devices instead of an integrated unit. And it is probably impossible if you have done something silly like totem-poled two routers.
There really is no programming question here at all unless you are willing to look at alternatives such as a TCP server that both clients connect to. Even that may be problematic if you have indeed wired two private-network NAT routers in a totem-pole configuration.
But I admit I am guessing about what the undocumented library (or libraries?) are doing.
I'm studying remote-debugging and try to find the cause of the problem. I'll post a new thread to discuss remote-debugging. Thank you, dilettante.
Re: RPC-Chat-Demo: Lan-Network (WIFI) connection test
Originally Posted by Jacob Roman
I can help with that. Basically for years I had the same problem. First of all (if you haven't already), you need to port forward your port number on your router that the server is running on. You can access your router settings using a particular ip address, and typically admin is the user name and password is the password. Next, on your router settings, you must enable DMZ to allow other computers from the outside world to access your computer. Then on your Windows machine, you need to give special permissions to your firewall to both the port number, and the server app to Incoming and Outgoing. Once you have all that, test to see if its accessible now with PFPortChecker.exe. If its successful, you are good to go. Just be sure your server is using the local ip and your client apps are using an external ip address. This is how I got my chat program going with the server made in C++ and my client apps on Android
Hi Jacob Roman, thank you for your reply. I'll perform a series of tests according to your method and feedback the test results.
Re: RPC-Chat-Demo: connection test in LAN (home WIFI)
Originally Posted by dreammanor
I started the RPC server first, and then started the RPC client (chat client).
In the chatclient login window, UDP could detect the IP address of the RPC server (the HostName TextBox was green),
So the (outgoing) UDP-Broadcasts were apparently successfull (as well as successfully received)...
Originally Posted by dreammanor
...but when the login button was clicked, the system popped up the following error message.
I would like to know what might be the reason for this error?
The UDP-stuff (which apparently works) is "one thing"...
... and it works only "on-top" of the normal RPC-functionality (which is based on TCP-connections).
First, you will (IMO) not have to change anything on your Router-devices...
Though on the Machine which hosts the RPC-Server-App, you will have to:
- adjust your Windows-Firewall to allow incoming TCP-Connections (for this "ExeName") on the TCP-Port the RPC-Server listens on (usually 22222 by default).
- the other thing on that ServerHost (which apparently works already) is to allow outgoing UDP-Broadcasts (on the Port which is configured for the UDP-stuff in that Demo).
That the outgoing (UDP) stuff (on the Server-machine) seems to be already working, is due to the fact that Firewalls
usually allow a bit more in outgoing- than in the incoming-direction one on a given machine.
Thats also the reason, why you will (in all likelihood) not have to allow the RPC-TCP-port (for outgoing RPC-requests) on your Client-Machine.
That said, (and assuming you will get it to work, when you enable incoming TCP-Requests on the Servermachines Port) -
the UDP-Broadcasting which is used in this Demo will work only for smaller SubNets in a LAN.
For a true Internet-Chat-App, you will have to switch to "polling with a dynamically adapted frequency"
(varying from about 3sec to 30minutes, depending on "user-activity", to check for new messages in a given Chat-Group) ...
If your Server can answer these (quite simple and quite optimizable) requests ("is there new data available for a given user in a given group") -
with about 2000 Responses per second, then you have "breathing-space" for about 1Mio concurrent Users of this App...
As an alternative to the polling (usually done later, when the Apps customers really reach "critical mass") -
you could switch to one of the "globally available Push-Services" (as e.g. those available from Google, or Mozilla-inc).
Re: RPC-Chat-Demo: connection test in LAN (home WIFI)
Originally Posted by Schmidt
So the (outgoing) UDP-Broadcasts were apparently successfull (as well as successfully received)...
The UDP-stuff (which apparently works) is "one thing"...
... and it works only "on-top" of the normal RPC-functionality (which is based on TCP-connections).
First, you will (IMO) not have to change anything on your Router-devices...
Though on the Machine which hosts the RPC-Server-App, you will have to:
- adjust your Windows-Firewall to allow incoming TCP-Connections (for this "ExeName") on the TCP-Port the RPC-Server listens on (usually 22222 by default).
- the other thing on that ServerHost (which apparently works already) is to allow outgoing UDP-Broadcasts (on the Port which is configured for the UDP-stuff in that Demo).
That the outgoing (UDP) stuff (on the Server-machine) seems to be already working, is due to the fact that Firewalls
usually allow a bit more in outgoing- than in the incoming-direction one on a given machine.
Thats also the reason, why you will (in all likelihood) not have to allow the RPC-TCP-port (for outgoing RPC-requests) on your Client-Machine.
That said, (and assuming you will get it to work, when you enable incoming TCP-Requests on the Servermachines Port) -
the UDP-Broadcasting which is used in this Demo will work only for smaller SubNets in a LAN.
For a true Internet-Chat-App, you will have to switch to "polling with a dynamically adapted frequency"
(varying from about 3sec to 30minutes, depending on "user-activity", to check for new messages in a given Chat-Group) ...
If your Server can answer these (quite simple and quite optimizable) requests ("is there new data available for a given user in a given group") -
with about 2000 Responses per second, then you have "breathing-space" for about 1Mio concurrent Users of this App...
As an alternative to the polling (usually done later, when the Apps customers really reach "critical mass") -
you could switch to one of the "globally available Push-Services" (as e.g. those available from Google, or Mozilla-inc).
Olaf
Sorry for the late reply. I'll conduct a series of tests as you said. Thank you, Olaf.