We enter the upper layers of the OSI model, and we do so through the most peculiar of the seven: layer 5, the session layer. It is peculiar because, unlike the four you have already walked through, you will never find "the layer 5 protocol" in any traffic capture: almost no real protocol implements it as a separate piece. And yet the problems this layer describes — who speaks now, where were we, how do we pick up after an interruption — exist in every real communication, and some piece of software always solves them. Understanding the session layer gives you two things: the vocabulary to recognize those problems wherever they appear (and they appear daily: expired sessions, downloads that resume, video calls that recover after a dropout), and the explanation of why the OSI map and the territory of real software don't match in the upper layers.

1. The session layer's role within the model
2. Service 1: establishing, managing and closing sessions
3. Service 2: dialogue control
4. Service 3: synchronization points and recovery
5. Why almost no protocol implements it separately
6. Where the concept lives today: three examples at Meridiano

First, let's distinguish two words that resemble each other dangerously:

• A connection (layer 4) is a transport channel between two processes: the TCP pipe between Marta's browser and the server's port 443.
• A session (layer 5) is a dialogue with context and continuity: "Marta's conversation with the intranet, authenticated as Marta, with her half-finished tasks in progress, from the moment she signed in until she signs out".

The difference shows when you ask: if the pipe breaks and another one opens, is the conversation still alive? With layer 4 alone, no: each new connection starts from scratch. The session layer is what OSI defines so the answer becomes yes: its job is to give the communication a life longer and richer than that of the connections carrying it.

Layer 5's OSI contract:

• What it receives from above (layer 6): data from applications that want to hold organized dialogues with memory.
• What service it offers: opening, maintaining, synchronizing and closing sessions; organizing the dialogue's turns; and marking checkpoints for resuming after a failure.
• What it uses from below (layer 4): transport connections between processes — which may be several, successive or simultaneous, all serving one and the same session.
• Its PDU: data (as in all the upper layers; from here on up there are no more headers with addresses of their own).

A session's life cycle has three phases, and in each one there are decisions someone must make:

1. Establishment: the two ends agree to start the dialogue and set its context: who they are (this is where authentication usually hooks in), which rules they will use, what identifier the session will have.
2. Maintenance: while it lasts, the session preserves state (who the user is, what has already been done) and watches that the other party is still there — the periodic keepalives, and the closures due to inactivity, are pure session management.
3. Closure: orderly (both agree to finish and free resources) or abrupt (one side vanishes and the other must detect it and clean up).

Notice that layer 4 does none of this on its own: TCP opens and closes connections, but it doesn't know who Marta is, remembers nothing between one connection and the next, and never decides when a dialogue "has expired". That meaningful state is layer 5's contribution.

Second service: organizing the turns. OSI distinguishes dialogues:

• Full-duplex: both ends can speak at once (a normal phone call).
• Half-duplex: speaking happens by turns, and someone must manage "the baton" of who holds the floor (a walkie-talkie: "over").

The term may sound dated, but the problem is current: in a video call, the software decides whose audio dominates and mutes echoes; in a booking system, when two users edit the same resource, someone manages who has the writing "turn" so they don't trample each other. Every time a piece of software coordinates whose turn it is, it is solving the problem OSI called dialogue control.

The most valuable service and the easiest to recognize today. The idea: in a long exchange, insert synchronization points — marks meaning "up to here, confirmed and safe" — so that, if something fails midway, you don't restart from zero but from the last mark.

Sound familiar? It is exactly what your browser does when an interrupted download resumes where it left off, or what Meridiano's backup tools do when the nightly sync with Bilbao gets cut and, on reconnecting, continues with the file it was on. The concrete mechanism varies (position markers, range requests, lists of already-confirmed blocks), but the concept is layer 5's synchronization point, exactly as OSI defined it forty years ago.

And now, the lesson's key question: if these services are so useful, why is there no "session protocol" running on Meridiano's server?

The reason is historical and practical at once. The OSI model was designed before and apart from the protocols that ultimately won. In the real Internet stack, session services turned out to be needed in very different ways depending on the application — a video call's session looks nothing like a website's — so nobody built a generic layer: each piece of software incorporated the session services it needed, its own way. The result is that layer 5 didn't disappear: it dissolved into three places:

Consequence for you as a professional: "session layer" is not a thing to configure, but a category of problems — maintained identity, continuity, turns, resumption. When one of those problems breaks, knowing "this is a layer 5 matter" tells you where to look: not in the network (layers 1-4, which may be flawless), but in the software managing that particular session.

The Monday meeting between Ana and Jon is a layer 5 festival. Before a single second of video flows, the video call software establishes the session: who is participating, what capabilities each side has, identifiers for the call. During the meeting, the session is maintained with periodic keepalives, and dialogue control manages the dominant audio. And best of all: if the VPN blinks for ten seconds, the call doesn't "die" — the transport connections break and get recreated, but the call's session survives and the video comes back on its own. That transparent reconnection is the connection/session distinction turned into user experience: layer 4 died; layer 5 (implemented by the application) lived on.

When Meridiano's administrator opens SSH against the .10 server, the whole cycle shows up in miniature: establishment with authentication (identity gets bound to the session), maintenance with state (the current directory, the remote environment variables: the server remembers where the administrator is between one command and the next), keepalives that detect whether the other end vanished, and orderly closure with exit, which frees resources on both sides. SSH integrates its session services inside the protocol itself: layer 5 dissolved into the application, working straight out of the textbook.

The most everyday case and the most instructive, because here layer 5 gets rebuilt on top of a protocol that doesn't have it: HTTP is stateless — each request arrives at the server an orphan, with no memory of the previous ones (you saw it in 02-05). So how does the intranet know that request number 40 is still Marta's? Because on authenticating, the server handed her a session identifier in a cookie (or a token), and the browser resends it with every request; the server keeps Marta's context associated with that identifier. That is, conceptually, a handcrafted session layer built at the application level. And its breakdowns are the most frequent layer 5 incidents you will handle: "the intranet kicked me out" (session expired due to inactivity), "it keeps asking me for my password" (the cookies don't persist), "I'm signed in on my laptop but not on the desktop" (the session lives in each browser, not "on the network"). In all of them, ping, DNS and TCP are flawless: no layer 1-4 tool will see anything odd, because the problem lives in the dialogue's state.

• Confusing session with connection. The connection is the pipe (layer 4); the session is the conversation with memory (layer 5). One session can outlive many connections (the video call after the VPN blink) and one connection can carry sessions from several users.
• Looking for layer 5 as a configurable component. There is no system-level "session service": these are functions spread across TLS, application protocols and each application's code. You diagnose it in the software, not in the network.
• Blaming the network for session problems. "It kicks me off the intranet every 10 minutes" with perfect ping and DNS is not a network problem: it is a session expiry policy or cookies that don't persist. Recognizing the layer saves you chasing ghosts through layers 1-4.
• Believing that since OSI "got it wrong" with this layer, it's not worth studying. On the contrary: the concepts (establishment, state, turns, synchronization, resumption) appear in every modern distributed system. What didn't stick was implementing it as a separate piece; the vocabulary is in daily use.
• Tip: when something "disconnects" or "kicks out" a user, first ask: what died, the connection or the session? And who manages that session: TLS, the protocol or the application? Those two questions steer the diagnosis to the right place.

Exercise 1. Classify each situation as session establishment/management/closure, dialogue control, or synchronization point: (a) the nightly backup toward Bilbao gets cut and on reconnecting continues with file 412 of 900; (b) the video call software gives Jon's audio priority while he presents and attenuates the rest; (c) the intranet kicks Marta out after 30 minutes of inactivity; (d) SSH asks for username and password before accepting any command.

Exercise 2. During the Monday meeting, the inter-site VPN drops for eight seconds. The video call freezes and recovers on its own; by contrast, a file transfer Jon had underway with another tool aborts and must be launched again from scratch. Explain both behaviors in terms of connection (layer 4) and session (layer 5). Which layer 5 service is the transfer tool missing?

Exercise 3. Marta calls support: "the intranet keeps asking me for my password, every two or three clicks". The ping to the server is perfect, DNS resolves and pages load fast. (a) Which layers can you consider good? (b) Where do you locate the problem, and why? (c) Give two plausible causes consistent with that diagnosis.

Solution 1. (a) Synchronization point (resumption from the last confirmed mark). (b) Dialogue control (managing turns/the dominant floor). (c) Session management/closure (expiry due to inactivity: a state-maintenance policy). (d) Session establishment (authentication binds identity to the dialogue before it begins).

Solution 2. In both cases the layer 4 connections died with the VPN outage: that is unavoidable and identical for both applications. The difference sits one layer up: the video call software maintains a session independent of its connections — when the network returns, it re-establishes new connections and re-associates them with the living session (call identifiers, participant state), and the user only sees a freeze. The transfer tool has no such level: its "dialogue" is its connection, and when that dies, everything dies. It is missing the synchronization point/resumption service: confirmed-progress marks that would let it pick up where it was on a new connection.

Solution 3. (a) Layers 1-4 are fine (ping, resolution, fast loading: network and transport work) — and the web service itself responds, so it isn't the previous lesson's "closed port" either. (b) In the application's session management (conceptual layer 5): asking for the password constantly means the server does not recognize Marta between requests — the session identifier isn't arriving, isn't persisting or isn't being accepted. (c) Plausible causes: Marta's browser blocks or deletes cookies (private mode, settings or aggressive cleanup), so each request arrives with no identifier; or the server's session expiry is misconfigured (an absurdly short lifetime that expires sessions almost immediately). Both fit an impeccable network.

The session layer defines the services that turn loose connections into dialogues with memory: establishment with identity, state maintenance, turn control and synchronization points for resuming without starting over. Its oddity is that in the real stack nobody implements it as a standalone piece: it dissolved into TLS, into protocols like SSH and RPC, and into the applications' own code — the cookies of Meridiano's intranet are a handcrafted layer 5 on top of a stateless HTTP. For you, it is above all a diagnostic category: when the network is perfect but the user "gets disconnected", "expires" or "can't resume", the problem is session-related and lives in the software. One more question remains that layers 1-5 don't answer: the data arrives whole, in order and within a living dialogue... but in what format does it arrive? With what encoding, compressed how, encrypted with what? The shape of the data is the business of layer 6: the presentation layer, next lesson.