I know I'm re-iterating a lot of things people have said here, but I just wanted to throw in my own wording on a few questions.
2. I'm using my own public IP address in the sf::TcpSocket.connect() function. Is this alright?
This depends; if by public IP you mean not your LAN IP, but the one that your
modem uses to connect to the internet (your
WAN IP) and you are behind a router, then no simply because your computer has no knowledge of what your router's IP address is; it only knows the one it was assigned (i.e. most likely a 192.168.x.x IP address).
2. I use the public IP to connect to a comp outside my router, right?
Further, you cannot connect to your WAN IP address from inside the LAN it belongs to. Look up host files.
If you are behind a router and want to have people from
outside your LAN connect to it, you must listen on a port on your
local IP (usually just specify 'all' IP addresses to bind to) and then port forward with your modem and/or router. See diagram.
3. Is this a reliable site to check if a port is open? http://www.yougetsignal.com/tools/open-ports/
Any sites work. See my warning below about port scanning.
However, if they are connecting from
inside the LAN, then they need to connect using the LAN IP address (i.e. 192.168.x.x).
If so, can I act as both server and client in order to test the program?
Yes, this is just fine. Keep in mind, however, that testing with a program just like Wireshark
will not work. Why? Because the computer is usually smart enough to realize it's connecting to itself, thus circumventing the actual NIC card entirely (to speed things up; it's a feature, not a bug!). This means that PCAP (the underlying driver that those programs usually use) won't detect it, and your packets won't show up.
You can, however, use WPE Pro; however, most AVs detect it as a virus (it is not) and it has very limited features and feedback (it was meant for editing packets and doing hack-ish kind of things moreover than debugging applications).
4. Can I use different computers with the same IP address in order to test the program?
Two computers cannot function on the same network with the same IP address. You can configure static IPs to be the same but the router will reject one of them (whichever is the second to connect).
5. What happens if I send a packet from the program to a random IP address and the port is open?
There are several answers to this question, the most blunt and simple answer would be "nothing". The chance of finding a random port on a random IP (without port scanning, which, depending on where you live or the terms you have with your ISP is extremely illegal, ESPECIALLY if you happen to scan, say, a government IP, which is a federal offence) is extremely slim (ports range from 1-65535).
Secondly, how it handles the data has two parts; what protocol does it use (TCP/UDP; basically, will it even connect?) and what program is using the port? Network activity doesn't care what the receiving program does with it; its job is to transport something to something else. That's it. The beauty of networking is that, not only can it (obviously) transport things across long distances, but that you could have
any program in any programming language send and receive data with another completely different program, so long as they know what they are talking about.
While UDP doesn't use connections, most of the time a server that receives a packet that it doesn't understand will simply ignore it. TCP servers generally accept any connect, perform some sort of authentication ("hey, how can I help you?" "Oh I am an IRC client" "Oh, you connected to a web server, I have no idea what you are talking about, goodbye"), which means it will refuse/disconnect any connections it doesn't recognize.
1. Would a connection using a cable LAN work the same way?
I meant connecting two comps with Ethernet cable.
It does; however, it's usually not as easy as you'd think. You usually have to get something called a 'crossover cable' because some of the connections need to be switched in the cable itself. A router actually takes care of this for you; direct connections do not.
So, If I open a port in a comp, that port is opened in all comps connected to the router?
Not quite. When you port forward, the router needs to know which computer to forward the data to (the router has no idea which ports are open on which computers; its job is to simply allow/refuse/direct traffic from one port to the others with IP addresses).
Usually when you port forward, it just forwards a port (heh) from the modem (WAN) IP address to a specific IP address that you supply. A lot of routers also support something called a 'virtual server' which is pretty much port forwarding, only you can specify a public port and a private port. This is useful if multiple computers are running the same software, and the software's listening port cannot be changed.
Or opening a port of a comp as in [snip .. windows firewall] is different from "port forwarding"?
Yes, simply because Windows Firewall wasn't built to route traffic like that. The firewall still has exceptions where things can get through, and often times it will refuse even
outgoing connections when they are 'open'.
I do a lot of socket programming, and I've never once needed to touch the windows firewall; I usually leave it disabled because it really doesn't do anything more than prompt you if a program can connect/listen on the first program run (I'm sure some people on here will disagree, but this is purely personal experience).
The example chat uses sf::Thread. Are threads speed independent of the game fps. So, for example, the "threads cycle" will run faster on a faster computer not matter if the fps is set to a specific value?
Or are threads co-dependent on the game's fps?
Depends on how you limit the FPS.
If you use setFramerateLimit then only the thread that holds the window will get limited and if you set VSync then only the thread that draws will be limited.
Keep in mind threads can be completely independent applications (see here for more information).
Two points I'd like to extend off of eXpl0it3r: one, each process itself has one thread to begin with as it is (the 'main thread', which is actually a special thread on most systems). Secondly, while threads operate independent of FPS, they are still limited by how much time the main operating system (more specifically the 'thread scheduler') gives to the thread. That is why sleep()-like functions that pause a thread are not accurate (unless you tweak some system configuration at runtime on Windows, for example, with timeBeginPeriod [only use if you know exactly what you're doing; you shouldn't use it unless you absolutely need the most accurate timing]).
Try not to laugh too hard.
Nobody was born knowledgeable about programming. We were all clueless at some point. These are all very good questions.
Best of luck.