wrote:

> 1)
> One of the session layer ( layer 5 in OSI model ) services is
> synchronization. In short, session layer inserts checkpoints into data
> stream, so that if the connection crashes, only the data after the
> last checkpoint has to be repeated.
> I don't understand the need for that, since TCP connection
> acknowledges the received packets and if connection crashes, why
> couldn't TCP make sure that only the data after the last acknowledged
> packet would have to be send. So why duplicate the work ( which
> transport layer already performs ) in session layer?

Okay, TCP does incorporate some of the functions of Layer 5. But here's
an example of when that might not be enough. Back in the bad old days of
dial-up networking, you'd sometimes (often) get dropped off by the
telco, just when you had downloaded the first zillion of three zillion
bytes. Some good applications allowed you, a long time later, to dial
back in and pick up where you had left off. This was typically a
completely different TCP session.

To me, that's a Layer 5 function. No matter in what shrink-wrapped
package it was included.

> 2)
> Session layer also performs dialogue control. Sessions can allow
> traffic to go in both directions at the same time, or in only one
> direction at a time. If traffic can only go one way at a time, the
> session layer can help keep track of whose turn it is.
>
> Can't TCP connection perform the same function - meaning, can't it
> somehow tell the other PC ( besides aborting connection ) when to send
> data and when to just listen?

You mean, can't TCP be rewritten to do this? Maybe, but it shouldn't be.
Because it's up to the application to decide whether this timing is
important or not. Something higher than TCP should, and does, make that
call.

Bert

In article <1182974839.125083.291130@k79g2000hse.googlegroups. com>,
kaja_love160@yahoo.com wrote:

> hello
>
> I'm sorry for making two threads in such a short time span, but this
> next question is rally bugging me
>
> 1)
> One of the session layer ( layer 5 in OSI model ) services is
> synchronization. In short, session layer inserts checkpoints into data
> stream, so that if the connection crashes, only the data after the
> last checkpoint has to be repeated.
> I don't understand the need for that, since TCP connection
> acknowledges the received packets and if connection crashes, why
> couldn't TCP make sure that only the data after the last acknowledged
> packet would have to be send. So why duplicate the work ( which
> transport layer already performs ) in session layer?

Acknowledgements tell you that the data was received by the destination
MACHINE and processed by its network stack. They don't tell you that
the data was received by the destination PROCESS. If the process
crashes, it won't read data that was received and acknowledged by TCP.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Bonjour Kaja,

For evolving in the Telecom understanding, you need to drop OSI model.
Today, the more adapted model is the TCP/IP model which existed prior
to the OSI model. It doesn't not mean that OSI was not useful!

In the TCP/IP model, a TCP/IP application is not an OSI application
(and, even, an application in short, as Word can be). The client of
the TCP protocol is generally a TCP/IP application protocol, or an
emulation of it.

For the lower layers, the ITU-T talks about, and more and more, of
layer networks, and not of network layers. In the layer networks,
there is a relation of client-server between adjacent networks (layer
networks). The differentiation with OSI is clear.

Best regards,
Michelot