The internet you actually deploy into

Most hosts do not have a real address

IPv4 addresses ran short, so most networks now use Network Address Translation. Inside the network every host takes a private, non-routable address from 10.x.x.x, 172.16.x.x–172.31.x.x or 192.168.x.x, and the router that faces the ISP owns the one address the outside world can see.

The router rewrites packets in both directions. On the way out it replaces your private source address with its own public one and remembers the mapping. On the way back in it looks up that mapping and rewrites the destination to your private address. As long as you started the conversation, this is invisible.

The consequence is not invisible at all: for an unsolicited packet arriving from outside, there is no mapping to look up. The router has no idea which internal host it belongs to and drops it. A server behind NAT is unreachable from the internet unless someone explicitly configures a forwarded port. Remember this — it is the failure that bites RMI in module 10.

Firewalls filter; proxies stand in for you

A firewall sits at the boundary and accepts or rejects each packet by rule, usually on address and port: outbound SSH allowed, inbound SSH refused, inbound port 80 allowed only to the one machine that is supposed to be a web server. It generally works at the transport or internet layer, so it judges envelopes rather than contents.

A proxy server goes further: it makes the request on your behalf. You ask the proxy, the proxy asks the origin server, the answer comes back through it. Because a proxy understands the application protocol it can inspect content, enforce policy, and — importantly for performance — cache, serving a page it already fetched for someone else. Two consequences follow. The origin server never learns your address, only the proxy's. And a proxy that knows HTTP and FTP does not know your protocol, so the custom protocol you design in module 9 will not pass through one.

Client, server, peer

The distinction is not about hardware or about who sends more data. The client initiates the conversation; the server waits for one. A web server is a program that waits; a browser is a program that starts. One program can be both, and a peer-to-peer design is exactly that — each side able to initiate and to wait. Java has no peer-to-peer API; you build it out of clients and servers, or route the peers through a meeting-point server that also solves how they find each other.

How the rules get written

Two bodies produce nearly everything you will implement. The IETF is open to anyone, works by rough consensus and running code, and standardises TCP/IP, MIME and SMTP; its documents are RFCs. The W3C is a paid-membership vendor organisation that tends to specify before implementing, and produced HTTP, HTML and XML.

An RFC, once published, is never edited — it can be obsoleted by a later RFC, but the text is fixed. The mutable, in-progress documents are Internet-Drafts. W3C work climbs five rungs: Note, Working Draft, Candidate Recommendation, Proposed Recommendation, and finally Recommendation, the top of the ladder.

Worked example — why your server works locally and not from campus

You write a server, bind it to 0.0.0.0:8000 on your laptop at 192.168.1.5 behind a home router whose public address is 216.254.85.72.

• From the same laptop, http://localhost:8000 works. Loopback: the packets never leave the host, so no router is involved.
• From your phone on the same Wi-Fi, http://192.168.1.5:8000 works. Both hosts are inside; the router switches locally and translates nothing.
• From a classmate on the internet, http://216.254.85.72:8000 fails, and fails silently — no error, just a connection that times out. The router receives the SYN, searches its translation table for an entry for inbound port 8000, finds none because it only creates entries for connections that started inside, and drops the packet.

The fix is a forwarded port on the router: an explicit rule mapping public 8000 to 192.168.1.5:8000. Nothing in your Java changes. Module 10 adds a nastier twist — an RMI server puts an address inside the stub it hands to clients, so it can hand out an address the client cannot reach even when the port is open.