Sign in to follow this  
Followers 0
qwert

Need advice on accessing PCs behind routers

11 posts in this topic

I've been able to get a simple AU3-based chat server running with three clients on my home network (all three machines behind the same router). All are using the "local" IP address ... starting with 192.161.1.... and everything works great. But now I'm trying to get it to work across the internet, with a router involved on both ends of the connection.

I have the IP address of the routers at each end ... plus, I've configured port forwarding on both routers and have temporarily turned off firewall protection -- all things I've learned about from help sites.

But, I'm unsure which IP addresses to place in the fields for the chat server and clients. At this point, I have both the server and my local copies of the client set with the same local host address ... and they communicate. I've configured a remote client with my (server) router's IP address ... and it cannot connect. BTW, I'm expecting that once a connection is made from the remote client, that router's address will be sent in and the server will respond to that external address -- so that it doesn't have to be specified anywhere. But I'm not positive that is correct.

I've been looking at this for two weeks and have read so many variations on "How To" that I'm somewhat lost as to which direction to go in. I will appreciate a "back to basics"-style explanation and some clear direction ... like maybe a simple ping test to try ... or maybe an AU3-based diagnostic script.

Thanks for any assistance.

Share this post


Link to post
Share on other sites



I got some knowledge about network. Here is the thing.

Differentiate 2 types of IP : public IP and private IP.

Public IP is provided by your ISP, it's also the IP of your router, if you are behind one.

Private IP is provided by your router, specifically by your DHCP server, is the IP of each pc inside that LAN, usually start with 192.168....

Now enter this case:

From a distance computer, you can't simply enter the private IP of your pc because there is no way your DNS server would find the way to reach there, because there are millions of PC in the world which have the private IP 192.168....

So what do you need to connect is the public IP, the IP of the router. But the problem here is that we stopped at the router. The router sees you send a traffic to him, but it doesn't know to which computer withing the LAN you want to send to. What you are going to do is a traffic redirection, or IP forward or something similar. So you configure you router by setting it that if it receive any traffic in a specific port, that you choose, then it has to automatically forward that traffic to a chosen pc at a chosen port.

Note that what I mentioned above is the direction server => client . Since there are many clients behind the router, the server doesn't know who to connect to. If there is no router, there would be no problem.

Now the direction client => server (assuming that the server side has no router). For the reason just mentioned, you can connect directly to the server. The client open a port and send a request to the server. The router automatically detects which remote port inside the LAN is opened and wish to connect to the server. When it receives a response from the server, it already knew which PC opened which port and automatically forward the response to the pc that made the request.

Simply remember these 2 things:

remote pc behind router => need traffic forward of that router

remote pc not behind router => can connect directly

Share this post


Link to post
Share on other sites

Thank you for the response.

I mostly follow what you are saying ... and it is close to what I've read on help sites. What I need at this point is to know which IP addresses I should place in the chat server and client(s). I have a attached a diagram of what I have at this point (and that is not working from the remote client). My main questions are:

What IP address should the Remote Client try to use?

Does the Remote Router also have to have port 5568 forwarded?

Is there a simple test I can run to confirm that the Routers are configured? ... like a ping?

As I mentioned, I have turned off firewall protection for my testing ... but I don't see any indication of message attempts from the remote PC.

.

post-29172-12864174614416_thumb.png

Share this post


Link to post
Share on other sites

What IP address should the Remote Client try to use?

the IP of the router on server side

Does the Remote Router also have to have port 5568 forwarded?

It depends on "who connects to who first". If the Remote Client connects first, the router on the client side automatically recognize which pc uses the port 5568 and send the request so no ip forwarding is require. But as it connects to the server, which is behind a router, the router on the server side needs to be configure, and vice versa.

If I were you then, yes, I'd configure both routers.

Is there a simple test I can run to confirm that the Routers are configured? ... like a ping?

ping doesn't work since all the packets will be stuck at the routers

Simplest test is to go the router configuration page. If it's a personal router, its private IP is 192.168.0.1, if it's a router provided by your ISP, you should go to the webpage of your ISP, login to your account then configure

As I mentioned, I have turned off firewall protection for my testing ... but I don't see any indication of message attempts from the remote PC.

Firewall is not an IP forwarding.

Here is an example how i configure my router

Posted Image

Any packets arrive at port 6112 & 6113 of my router will be forwarded to port 6112 & 6113 of my pc (192.168.0.10)

- client listens on port X

- server sends a request to client, asking for connection

=> sends packet to router Server

=> router Server chooses a random port and sends packet to router of Client on port Y

- Client router receives the packets on port Y => forwards to Client on port X

- Client accepts the connection on port X, and so on.

architecture: (host::port)

Server::p1 | p2::Router::p3 <========> p4::Router::p5 | p6::Client

Share this post


Link to post
Share on other sites

Thanks. I think I follow your answers and will be able to test tomorrow. But I do have one question that results from the router example you included.

You have ports 6112 and 6113 configured for both TCP and UDP. Which should I be using? Or do I need both? I admit, I don't really understand the difference, except that TCP seems to be for applications that "open a port" and UDP is for receiving "unsolicited inquiries". But I don't know which type the chat application requires or expects.

Can you shed some light on this issue?

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

TCP is the most commonly use. They are both protocol to send data.

TCP have a control protocol, when a packet is lost or have error, the protocol ensure the retransmission of the packet, therefore ensure the best synchronization between 2 sides. You receive a letter a when you want to send a letter b...

UDP sends information faster, due to the lack of security and data control. Use this when you want to send video/music/phone voice data. Things that are not important, it's ok if there's some small error, when quantity > quality

Edited by trung0407

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

Thanks. I think I follow your answers and will be able to test tomorrow. But I do have one question that results from the router example you included.

You have ports 6112 and 6113 configured for both TCP and UDP. Which should I be using? Or do I need both? I admit, I don't really understand the difference, except that TCP seems to be for applications that "open a port" and UDP is for receiving "unsolicited inquiries". But I don't know which type the chat application requires or expects.

Can you shed some light on this issue?

I'll pitch in to answer that one for you.

Before answering the question, perhaps there is a terminology clarification that will help you.

A 'server' is a program that listens on a port, ready to respond. When it gets a query it can understand, it replies back to the address the query came from. It never initiates the conversation.

A 'client' always starts the conversation, and therefore it must know the address of the server to get things started.

(A single program can have both a 'server' listener and a 'client' conversation-starter section, depending on what the programmer is after.)

Therefore the router at the server location must have port forwarding set up so that queries from the remote client coming in get routed to the local address of the server, as shown above.

The router on the client side does not need this rule if communications are via TCP. If UDP is being used, the client's router might need the same rule, directing incoming traffic to the local address of the client computer. So now this gets us to the difference between TCP and UDP.

TCP is a two-way protocol that forms a 'connection' between machines. Under the hood, it includes error-checking to make sure each packet is understood correctly by the receiving machine. That means for every slug of data the receiving machine gets, it automatically replies to the sender with a code. If the code doesn't match what was sent, or if the sender never gets a reply, the slug is sent again. So, there's a two-way conversation, even if the info you want to send is only one-way.

A router knows this and checks the header of every packet going out and coming in. So if the client sends a TCP query to the server, the router at the client knows this, and expects a TCP packet coming back from the address it just sent the packet to. That's why the router doesn't need to have the port forwarded, because the client always initiates conversations outbound. If the router gets a packet from the big bad internet that is not a reply to a recently sent outbound TCP packet, it simply ignores it.

UDP is a 'connectionless' protocol. Each packet of data is sent 'in the blind'. The receiver is not expected (at the protocol level) to respond. If any error checking is to be done, or accounting for packets that get lost en route, etc, then it will be the responsibility of the program using that protocol to take care of it in whatever way the programmer wants to invent, or make the program tolerant of missing or corrupted packets. This scheme is used because it greatly reduces the actual traffic on the wire for a given amount of data. Game servers use it a lot where latency is important and bandwidth is precious. The game client simply has to deal with the unreliability of the data stream.

Be aware that a lot of applications use a TCP session to set up the conversation first, then switch over to UDP, and maybe on a different port.

So, because a response to a UDP packet is not required by the protocol, if your application uses UDP, you will most likely need to port forward those packets at the client end. That's why, on a lot of chat applications, you'll see them specifying various ports to forward for TCP and/or UDP.

I hope that clarifies things instead of muddying the water even more.

--97T--

Edit: You wrote, "I've been able to get a simple AU3-based chat server running", then you wrote, "I don't know which type the chat application requires or expects."

If you have the code, it'll tell you which protocol is being used. If it's not obvious, give us some information about what the code is doing and we can determine for you.

Also, there's another glitch waiting to get you; when you are doing port forwarding stuff on your router, you'd better make sure the computer behind the router has a static address. If you've got everything set for DHCP (automatic addressing), then your server or client is probably going to get different internal addresses assigned to it based on the order the computers get started up behind that router. Most routers have a way to always assign a specified address to a machine based on the MAC address of the network card in the machine. Or you can turn DHCP off and assign all the IP addresses in your private network yourself.

Edited by NinerSevenTango

Share this post


Link to post
Share on other sites

TCP is a two-way protocol that forms a 'connection' between machines. Under the hood, it includes error-checking to make sure each packet is understood correctly by the receiving machine. That means for every slug of data the receiving machine gets, it automatically replies to the sender with a code. If the code doesn't match what was sent, or if the sender never gets a reply, the slug is sent again. So, there's a two-way conversation, even if the info you want to send is only one-way.

A router knows this and checks the header of every packet going out and coming in. So if the client sends a TCP query to the server, the router at the client knows this, and expects a TCP packet coming back from the address it just sent the packet to. That's why the router doesn't need to have the port forwarded, because the client always initiates conversations outbound. If the router gets a packet from the big bad internet that is not a reply to a recently sent outbound TCP packet, it simply ignores it.

UDP is a 'connectionless' protocol. Each packet of data is sent 'in the blind'. The receiver is not expected (at the protocol level) to respond. If any error checking is to be done, or accounting for packets that get lost en route, etc, then it will be the responsibility of the program using that protocol to take care of it in whatever way the programmer wants to invent, or make the program tolerant of missing or corrupted packets. This scheme is used because it greatly reduces the actual traffic on the wire for a given amount of data. Game servers use it a lot where latency is important and bandwidth is precious. The game client simply has to deal with the unreliability of the data stream.

Yes, this explanation helps a lot.

In answer to your question, I based my scripts on the "New and Improved TCP Chat" from this forum post:

http://www.autoitscript.com/forum/index.php?showtopic=112507&st=0&p=788210&hl=chat&fromsearch=1&#entry788210

Although it clearly says TCP, does that rule out TCP/UDP switching? I see TcpSend and TcpAccept used throughout, but I don't know what role "sockets" play. I will certainly appreciate a conclusive determination.

Thanks very much for your help on this.

Share this post


Link to post
Share on other sites

consider a socket as a tunnel join 2 sides of the communication.

Share this post


Link to post
Share on other sites

And yes, it looks to be all TCP.

'Socket' is terminology used to describe Windows functions to form a connection between your application and the network interface card, more or less. The functions used in that example take care of establishing that for you.

Share this post


Link to post
Share on other sites

its kinda simple once you understand Router switching.

usually all you have to do (from my own experience) is have the TCP server on a machine with its router forwarding a port to the local machine.

---ex)

---router ip 216.73.64.90

---server ip 10.50.50.178\4444

---client must connect to router's ip 216.73.64.90, the router must forward all traffic comming on port 4444 to ip 10.50.50.178, client does not need to know the serve'rs local machine ip at all.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0