コンテンツにスキップ
SteveTechArcSteveTechArc Courses

Finding the Server

このコンテンツはまだ日本語訳がありません。

Module 2 of 5 in the chapter The Client and Server, chapter 2 of the Integration Architect course. Each module stands on its own. Previous: Who Dials the Phone · Next: Knocking on the Door

The question this module answers: What does a client need to know to reach a server, and what has to be true on the server’s side?

Here’s the question I ask the room. For a client to call a server, what does it have to have?

The first answer is usually authentication: it needs some way to prove who it is. Good. The next one is an IP address, or a domain. Also good. And then: it needs to know what language the server speaks.

So the client needs three things: where the server is, how to prove who it is, and how to talk to it. This module is the first one, where. Module 3 is how it knocks on the door, and chapter 3 is the language.

An Address

Section titled “An Address”

Which kind of address the client uses depends on how far away the server is. There are three distances worth knowing.

Inside one machine: localhost. When one process on a machine needs to reach another process on the same machine, it calls localhost. That’s a special address that always loops back to the machine you’re on, 127.0.0.1. Because both processes are on the same machine, the address alone doesn’t say which one you want, so localhost almost always comes with a port, such as localhost:5000 (ports are next). A developer running a server on their laptop and calling it from the same laptop is doing exactly this. It’s the shortest possible integration: two processes on one machine, the case from the last module.

Inside one machine: localhost One machine with two processes in it. Our process, the client, tagged dials, calls another process on the same machine, listening on port 5000, at localhost:5000. Underneath: inside one machine, localhost always loops back; the port says which process. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.50.0", "built": "2026-10-28", "id": "DGM-INT-CS-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.4.0", "theme": "stevetecharc 1.4.0"} ONE MACHINE Our process the client dials Another process listening on port 5000 localhost:5000 Inside one machine, localhost always loops back. The port says which process. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Inside one machine: localhost, and a port to say which process.

Inside your own network: an IP address. An IP address is a number that identifies a machine on a network, such as 203.0.113.10. That’s how computers find each other underneath everything else. Inside your own network, behind your own firewalls, in your own data center, systems often call each other by IP address. That can work, because the people who run that network know when an address changes, and can change the callers with it.

The downside is that an IP address usually takes you to a single machine. If that machine goes down, the client is lost. It has the right address for a machine that isn’t there.

Inside your network: an IP address Two machines in your network. Our process, the client, tagged dials, on this machine, calls a service on another machine by its IP address and port, 10.0.0.7:8080. Underneath: inside your own network, an IP address can work; but it is one machine, and if it goes down, the client is lost. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.50.0", "built": "2026-10-28", "id": "DGM-INT-CS-05", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.4.0", "theme": "stevetecharc 1.4.0"} YOUR NETWORK: THIS MACHINE YOUR NETWORK: ANOTHER MACHINE Our process the client dials A service at 10.0.0.7, port 8080 10.0.0.7:8080 Inside your own network, an IP address can work. But it is one machine: if it goes down, the client is lost. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Inside your network: an IP address can work, but it’s one machine.

Outside, and at scale: a name. As soon as you’re talking across networks, to a partner or a cloud service, or you need more than one machine to carry the load, you want a name. A name can point to a load balancer: something that stands in front of several servers and spreads the calls across them, so that more calls can be handled, and one machine going down doesn’t stop the service. Behind the name, individual machines can be added, removed and replaced, and their IP addresses can change, while the client keeps calling the same name. That’s how a service stays up while the machines underneath it are rotated.

And not everyone knows the IP addresses anyway. People don’t remember numbers, and a partner shouldn’t have to know which machines you run.

A domain is a name like steve-trucking.example. A subdomain is where you put a name to the left of the dot: api.steve-trucking.example, portal.steve-trucking.example. Each one can point to a different place, a machine or a load balancer, and each one can have its own listeners responding to traffic.

What comes after the slash is different. api.steve-trucking.example/manifests and api.steve-trucking.example/orders go to the same place: the same service behind that name. It’s that service that decides what each path means. The name gets you to the building; the path is what you ask for once you’re inside.

And how does a name become an address? The client looks it up in DNS, the internet’s address book: it asks for the name and gets back an address to connect to. You met DNS in the last module of chapter 1, as one of the things that can stop an arrow when both systems are up. Now you can see why: if the client can’t look up the name, it never finds the address, and the call never starts.

Outside your network: a name Your network on the left, outside your network on the right. Our process, the client, tagged dials, first asks DNS, the internet's address book, where api.redrock.example is. Then, in navy, it calls that name on port 443 and reaches Redrock's load balancer, which spreads the calls over servers that are added and replaced. Underneath: outside your network, call a name; behind it, machines can be replaced and their addresses change. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.50.0", "built": "2026-10-28", "id": "DGM-INT-CS-06", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.4.0", "theme": "stevetecharc 1.4.0"} YOUR NETWORK OUTSIDE YOUR NETWORK Our process the client dials DNS the internet's address book Redrock's load balancer spreads calls over servers that are added and replaced 1. where is api.redrock.example? 2. calls the name, on 443 Outside your network, call a name. Behind it, machines can be replaced and their addresses change. HOW TO READ IT a call to a name, not to one machine © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Outside your network: look the name up, then call the name. Behind it, the machines can change.

Your Port Is Like the Phone Number

Section titled “Your Port Is Like the Phone Number”

Finding the machine isn’t enough. One machine can run many services, and each one listens on its own port. If the IP address is the building, the port is the phone number inside it. You can reach the building and still dial the wrong number.

A few port numbers are an industry standard across the world, kept in a registry by IANA, the body that assigns them (Service Name and Transport Protocol Port Number Registry (opens in a new tab), checked 2026-11-01):

  • 80 is plain HTTP, the web without encryption.
  • 443 is HTTPS, the secure web.

If you leave the port out of an https:// address, 443 is implied. If a server listens somewhere else, you put the port after a colon: https://api.steve-trucking.example:8443.

One correction to something I’ve said in class. I’ve called 443 “authenticated.” That isn’t quite right, and it’s worth being precise. On 443, the traffic is encrypted with TLS (TLS 1.3, RFC 8446 (opens in a new tab)), and the server’s certificate proves to the client that it’s talking to the real server. But the port doesn’t check who’s calling. A client on 443 still has to prove who it is, and that’s the next module.

Here’s a Salesforce example of why ports matter on a real project. Salesforce’s Pub/Sub API, which we’ll use for events in chapter 11, has its own endpoint, and the quick start uses port 7443: “The gRPC channel points to the Pub/Sub API endpoint api.pubsub.salesforce.com:7443. In this quick start, we use port 7443, but you can alternatively use port 443.” It also asks you to make sure your firewall allows the Pub/Sub API endpoint. (Step 2: Build the Python Client (opens in a new tab), Pub/Sub API quick start, checked 2026-11-01.) If the network team only opened 443 and the developers wrote 7443, the client has the right name and the right address, and the call still never connects. Somebody has to decide the port, and tell the people who run the firewall.

Someone Has to Be Listening

Section titled “Someone Has to Be Listening”

Now turn around and look from the server’s side. For any of this to work, the server has to make itself available, through an IP address or a domain, and it needs a process that’s up and running and listening for connections on that port. Most of the time, we call those web servers. If it’s secure, it listens on 443 or a port it has chosen and published.

If nothing is listening, it doesn’t matter how good the client’s address is. The call is refused, or it hangs until it gives up. And remember the rule from the last module: the server won’t call back. It’s the client that finds out, and the client that has to decide what to do: wait, retry, or tell someone.

Putting It Together

Section titled “Putting It Together”

Here’s Redrock’s call from the last module, before anyone says a word.

Finding the server Redrock's call, read top to bottom, with calling a company beside it line for line. Redrock knows the server's name, api.steve-trucking.example: you know the company's name. It looks the name up in DNS, the internet's address book: you look up where they are. It gets an IP address, 203.0.113.10: you have the building's address. It connects to a port, 443, the standard for HTTPS: you dial the right phone number in it. And, highlighted, a server is listening, a web server up and waiting on 443: someone is there to pick up. Underneath: a name, an address, a port, and someone listening; miss any one, and the call never connects. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.50.0", "built": "2026-10-28", "id": "DGM-INT-CS-03", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "flow/sequence 0.1.0", "theme": "stevetecharc 1.4.0"} Redrock knows the name api.steve-trucking.example You know the company's name. It looks the name up DNS, the internet's address book You look up where they are. It gets an IP address 203.0.113.10 You have the building's address. It connects to a port 443, the standard for HTTPS You dial the right phone number in it. A server is listening a web server, up and waiting on 443 Someone is there to pick up. CALLING A COMPANY A name, an address, a port, and someone listening. Miss any one, and the call never connects. HOW TO READ IT a step the step that matters most what comes next © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

A name, an address, a port, and someone listening.

Every one of those steps is something the client needs to know, and something that can fail. The name can be wrong, DNS can be down, the port can be blocked, the listener can be stopped. That’s why, on a project, I want them written down for every arrow, not left in someone’s head.

The names and the address in this module are reserved for examples (RFC 2606 (opens in a new tab), RFC 5737 (opens in a new tab)), so no real business is behind them.

What an Architect Decides Here

Section titled “What an Architect Decides Here”
  • For every arrow, the server’s name (domain or subdomain), and who owns it in DNS.
  • The port each server listens on, and that every firewall in between allows it.
  • Which server is listening, who keeps it running, and what the client does when it isn’t.
  • Which kind of address each client uses: localhost within a machine, an IP address only inside a network you run, and a name for anything outside it or behind a load balancer.
  • Separate names for separate services where it helps, so one can move without changing the others.
  • That every one of these is written down for each arrow, not left in someone’s head.

Explore

Section titled “Explore”