C++ Networking- port forwarding

[amerninja2]

So in C++, using Something like Unix Sockets or Winsock with C++ lets you use things like TCP/IP. But it only lets you connect to an IP within your router when its by itself.

How can I have the program somehow forward the connection to like an HTTP server or something (Hyper text transfer protocol, website), and have the other side connect to the server at the same time on a whole other router, and then the HTTP server receive messages from one, and forwards it to the other.

That way you can be on the other side of the world like any other I.M program.

------------
Also, what do you best recommend for a socket library that can be used on Unix, Windows, and maybe Linux? If there isn't any others that can be used other than Unix Sockets, and Winsock, then i'll just have to learn both and then use the startup functions for Windows when using Winsock (I don't know how to have the program detect the OS though...).

[Ancient Dragon]

>>So in C++, using Something like Unix Sockets or Winsock with C++ lets you use things like TCP/IP. But it only lets you connect to an IP within your router when its by itself.

False. Try making the address something like this: "http://www.DaniWeb.com" and you can connnect to it via tcp/ip.

[Comatose]

I strongly suggest using sdl_net for your socket work. I've found it to be a very nice cross-platform socket library, with quite a bit of functionality. It has a couple of quirks, but they are minor, and easy to work around.

As A.D. Suggested you would need to connect to daniweb.com, and then choose port 80... then you should connect, but you'll have to send an http request header... however, connecting directly out without needed to use an HTTP server... unless you are trying to work on some kind of proxyish, bypass firewall rule thing. In which case, I don't see why you don't just run the server on the web port (80 or 8080) anyway.

[amerninja2]

>>So in C++, using Something like Unix Sockets or Winsock with C++ lets you use things like TCP/IP. But it only lets you connect to an IP within your router when its by itself.

False. Try making the address something like this: "http://www.DaniWeb.com" and you can connnect to it via tcp/ip.

Ohhh O.K.
But is there a way to have the HTML coding of a website somehow respond to incoming connections and forward the messages sent to the server from them to another connection?

With that, a way for the user's program to receive messages from the website server?

[Comatose]

No. That's not what web-servers do. You can write a program that listens on port 80 (web port) and have that accept connections from clients. Then you can have that program send any data to any other connection.... what exactly are you trying to do?

[amerninja2]

No. That's not what web-servers do. You can write a program that listens on port 80 (web port) and have that accept connections from clients. Then you can have that program send any data to any other connection.... what exactly are you trying to do?

I know what web servers do, I have my own website that is partly made up of pure HTML and Javascript.

But with C++, I wanna create an instant messenger like any other that lets you connect to someone really far away like on the other side of the planet. It doesn't let you connect to someone else outside of your wireless router even if they're listening on a port that your connecting to...

So if they both connect to an HTTP server, the server could forward messages from one to the other back and fourth so that their computer's firewall lets the connection work...

[Jiropole]

What scripting languge are you using? using cURL libraries you can make server->server connections, so your client can connect to the server, then the server can relay a message to another server. But in the case of HTTP clients, polling is the only way to keep the info flowing. In that case, the easiest way to build an HTTP chat client is to simply have clients poll a server for updates, and the server accepts chats and stores them, and relays them to the appropriate client the next time that client polls for data.

[amerninja2]

What scripting languge are you using? using cURL libraries you can make server->server connections, so your client can connect to the server, then the server can relay a message to another server. But in the case of HTTP clients, polling is the only way to keep the info flowing. In that case, the easiest way to build an HTTP chat client is to simply have clients poll a server for updates, and the server accepts chats and stores them, and relays them to the appropriate client the next time that client polls for data.

Well I'm going to make a C++ program using Sockets or Winsock, and that will connect to the HTTP server.

With the HTTP server, I'm only using HTML and Javascript.

[Comatose]

I know what web servers do, I have my own website that is partly made up of pure HTML and Javascript.

Ok, so then you also know that web servers don't maintain a persistent connection. Which means that the connection doesn't stay alive. Which means as soon as the web server is done dishing out the web page to the client (or any information to the client) it immediately disconnects. So... let's follow this scenario:
1) you connect to the web server
2) buddy connects to web server
3) web server d/c you
4) buddy tries to send you a message, and is also d/c
5) web server..... does what? Sends you a message over a broken TCP connection?

[Jiropole]

Well, to do what I'm talking about you'll need some kind of dynamic scripting on the server to accept, store and respond to chat polling. Otherwise, for HTTP or any other protocol, your client has to actually run a server itself, requiring that an incoming port be both open and not in use by another service. Most clients try to ensure they not require any special incoming ports be available, and instead the server does all the work of accepting requests and sending responses. Then only the server machine has special incoming port needs (e.g. 80).

So, client1 sends a chat to the server. The server stores it. client2 is polling the server every N seconds, and when a message addressed to client2 is available, it is sent in response to client2's poll request as the HTTP response.

Update: it is also possible to run the above scenario with a connection-oriented protocol. However, HTTP is not connection oriented, as Comatose points out. You can build your own messaging protocol, but then you'll need to build a dedicated server as well. Apache will not do it.

[amerninja2]

Ok, so then you also know that web servers don't maintain a persistent connection. Which means that the connection doesn't stay alive. Which means as soon as the web server is done dishing out the web page to the client (or any information to the client) it immediately disconnects. So... let's follow this scenario:
1) you connect to the web server
2) buddy connects to web server
3) web server d/c you
4) buddy tries to send you a message, and is also d/c
5) web server..... does what? Sends you a message over a broken TCP connection?

Omg... You and your buddy are connected at the same time. When the server receives a message from one, it forwards the message to the other person. So their both connected to the server, and the server responds to their connection.