1. You'd need a (server) program running on your local computer listening on one or more external ports (such as "eth0"). The "lo" (loopback) port isn't sufficient.
2. You'd need to make sure that your computer doesn't have a firewall blocking whichever port(s) your server program listens to. Otherwise requests cannot make it into your server computer.
3. You'd need to make sure that there aren't any other firewalls blocking requests between the client computer and your server computer. Some Internet Service Providers won't pass traffic except for specific ports such as SMTP email (25), HTTP/HTTPS (80/443), and possible a few others. It doesn't matter if it's your ISP or the other person's ISP or somewhere in between. A blocked port is a blocked port.
4. The client machine needs to know how to find your server machine. That ultimately means knowing your server's IP address. That address must not be one of the non-routable internal-use IP addresses such as 192.168.x.x or 10.x.x.x, UNLESS both client and server are on the same LAN or VPN. The private addresses cannot be accessed over the open Internet.
5. The client can use a resolver so that instead of having to type in the server's numeric IP address, the client could use a Domain Name such as "www.coderanch.com". A resolver is basically like a telephone book. Look up www.mousetech.com and for many years you'd get back 216.199.14.18, although I have a new IP address for that name now - like getting a new phone number. The most common resolvers are DNS servers and the local machine's "hosts" file, but any mechanism that can translate a name to an IP address will do. Your client has to know what port, however, since DNS only resolves IP addresses, not port numbers. Many protocols - such as http - have a default Well-Known-Port number (http is 80). That's why when you work with a server like
Tomcat that listens for HTTP traffic on port 8080 instead that the client has to explicitly request that port ("http://www.mytomcat.com:8080").
