Re: Does socket represent an interface between ... ?
On Jun 14, 4:21 am, don provan <dpro...@comcast.net> wrote:
[color=blue]
> But let's not forget that it's a 7-layer model, not a four layer
> model. Do you know what happened to the top three layers?[/color]
I consider them bundled with the application program. For example, the
web browser software launches each session, not a separate module.
I don't know how these applications are written. I wouldn't be
surprised if much of the same "session layer" code were not common to
applications like MS IE and Office, for example. I know if I were
writing that code, I'd certainly do a lot of cutting and pasting. Same
goes for the presentation layer. How you decode integers, floating
point, ASCII, images, etc. is certainly something that you won't
reinvent for every application you write.
Looking down at the bottom, I think there's not so much doubt
concerning the difference between the physical layer and the data link
layer, right? The old RFCs used to lump those into a "communication
network" layer, for example, or "communication network service
interface," or "local network protocol." It depends which RFC you look
at. Surely, the 7-layer model is a more accurate portrayal of how
networks really work, in these bottom layers.
[color=blue]
> In short, a lot of it really wasn't right, and even some that was
> logically reasonable is now, given what actual "network layer" and
> "transport layer" and "application layer" protocols have been
> implemented, inaccurate in practice.[/color]
I consider it to be more right than wrong. This is all mostly of minor
importance, as you say, but only as long as the people debating
understand the structure already. Kids just starting off should not,
IMO, be told that the 7-layer model is irrelevant.
The more basic problem is that NOT understanding the idea of a layered
protocol stack is really a big handicap. It's like any other subject
matter. You need to understand the basic structure to have a clue
what's going on. How do radios work? How do automobiles work? How do
cameras work? If you don't understand the building blocks, everything
is just one, big, mysterious black box.
Bert
Re: Does socket represent an interface between ... ?
Albert Manfredi <bert22306@hotmail.com> writes:
[color=blue]
> On Jun 14, 4:21 am, don provan <dpro...@comcast.net> wrote:
>[color=green]
>> But let's not forget that it's a 7-layer model, not a four layer
>> model. Do you know what happened to the top three layers?[/color]
>
> I consider them bundled with the application program. For example, the
> web browser software launches each session, not a separate module.[/color]
Right, which is the point: they *are* bundled up, they are *not*
"layered".
[color=blue]
> Looking down at the bottom, I think there's not so much doubt
> concerning the difference between the physical layer and the data link
> layer, right? The old RFCs used to lump those into a "communication
> network" layer, for example, or "communication network service
> interface," or "local network protocol." It depends which RFC you look
> at. Surely, the 7-layer model is a more accurate portrayal of how
> networks really work, in these bottom layers.[/color]
Well, no, actually. The outlook in the IP world is, as you say, that
there's an undefined packet carrying mechanism under IP. Whether it
has two layers or one or six is of no interest to IP, nor should it
be. By defining that layer as "two layers, the datalink protocol and
the hardware," you've ruled out tunnels and VPNs where and other
contraptions where the network layer, without know it, is actually
sending packets over another network layer. So the 7-layer model got
your through the simple topographies, but at the expense of making
more complex situation potentially harder for someone to understand.
[color=blue]
> I consider it to be more right than wrong. This is all mostly of minor
> importance, as you say, but only as long as the people debating
> understand the structure already. Kids just starting off should not,
> IMO, be told that the 7-layer model is irrelevant.[/color]
Well, perhaps that's because you grew up with it. To me, it's still
just a marketing trick OSI supporters tried to pull to advertise OSI.
Yeah, those posters you get at trade shows and put up in your office
with the protocol headers on them can be useful, but they still leave
out the protocols that compete with ones the poster is trying to sell
you.
[color=blue]
> The more basic problem is that NOT understanding the idea of a layered
> protocol stack is really a big handicap.[/color]
Yeah, I'll give you that. As I've said, it's not so much that it's bad
the 7-layer model is there, but a question of how much better of a
model would have taken its place if it hadn't been there.
-don
Re: Does socket represent an interface between ... ?
In article <ufy4snu7e.fsf@comcast.net>, don provan <dprovan@comcast.net>
wrote:
[color=blue]
> Albert Manfredi <bert22306@hotmail.com> writes:
>[color=green]
> > On Jun 14, 4:21 am, don provan <dpro...@comcast.net> wrote:
> >[color=darkred]
> >> But let's not forget that it's a 7-layer model, not a four layer
> >> model. Do you know what happened to the top three layers?[/color]
> >
> > I consider them bundled with the application program. For example, the
> > web browser software launches each session, not a separate module.[/color]
>
> Right, which is the point: they *are* bundled up, they are *not*
> "layered".[/color]
Even inside applications, there are usually identifiable layers. For
example, look at a typical terminal application for a PC. There is code
that deals with TCP connections, code that deals with telnet or ssh stuff,
and code that deals with emulating an ANSI-X3.64 (or whatever) terminal.
These map (more or less) to layers 5-7 (session, presentation, and
application).
In a well-designed application, you can swap components around at each
layer without affecting the other layers. The choice of whether to emulate
a VT-100 or an ADM-5 terminal can be made without regard for whether you're
running telnet, ssh, rlogin, or whatever.
Re: Does socket represent an interface between ... ?
On Jun 16, 8:57 am, Roy Smith <r...@panix.com> wrote:[color=blue]
> don provan wrote:[/color]
[color=blue][color=green]
> > Right, which is the point: they *are* bundled up, they are *not*
> > "layered".[/color]
>
> Even inside applications, there are usually identifiable layers. For
> example, look at a typical terminal application for a PC. There is code
> that deals with TCP connections, code that deals with telnet or ssh stuff,
> and code that deals with emulating an ANSI-X3.64 (or whatever) terminal.
> These map (more or less) to layers 5-7 (session, presentation, and
> application).
>
> In a well-designed application, you can swap components around at each
> layer without affecting the other layers. The choice of whether to emulate
> a VT-100 or an ADM-5 terminal can be made without regard for whether you're
> running telnet, ssh, rlogin, or whatever.[/color]
Exactly my point.
Also, the layered model is not supposed to represent *just* what
applies to the IP stack. It's supposed to represent the whole
networking subject matter.
Analogies are always questionable, but please indulge me. If you're
talking about cars, we all know there's something called the
"drivetrain." This functional block is what turns engine power into
vehicle motion. Two of it's most important subblocks are the
transmission and the differential.
Just because some cars use a combined unit, usually called
"transaxle," does not mean that a model where transmission and
differential are separated is "wrong." It simply makes it a model with
more granularity.
Bert
Re: Does socket represent an interface between ... ?
In article <1182028511.966852.118440@n2g2000hse.googlegroups.com>,
Albert Manfredi <bert22306@hotmail.com> wrote:
[color=blue]
>Also, the layered model is not supposed to represent *just* what
>applies to the IP stack. It's supposed to represent the whole
>networking subject matter.[/color]
No, the OSI 7-layer model is only a rough approximation properly used
as a teaching aid with the completely ignorant and naive or as a very
rough, known to be wrong shorthand among the knowledgablie. It is also
used by authors of trade rag inter-ad filler and others to demonstrate
their (bogus) expertise and bamboozle the completely ignorant and naive.
[color=blue]
>Analogies are always questionable, but please indulge me. If you're
>talking about cars, we all know there's something called the
>"drivetrain." This functional block is what turns engine power into
>vehicle motion. Two of it's most important subblocks are the
>transmission and the differential.
>
>Just because some cars use a combined unit, usually called
>"transaxle," does not mean that a model where transmission and
>differential are separated is "wrong." It simply makes it a model with
>more granularity.[/color]
I like that analogy. Talk about a "drive train" is fine when you are
explaining cars to someone who knows nothing under the hood or as a
rough shorthand, even when talking about electric cars without good
equivalents to transmissions or differentials. On the other hand, it
is kooky to argue or even care about whether individual motors on wheels
are drive train sub-layers of limited slip differentials because there
are no ring gears and pinion or because they divide torque among the
wheels better than Positraction(tm).
As the saying goes, "Layering is a good tool but a bad master."
Vernon Schryver [email]vjs@rhyolite.com[/email]
Re: Does socket represent an interface between ... ?
Albert Manfredi <bert22306@hotmail.com> writes:
[color=blue]
> On Jun 16, 8:57 am, Roy Smith <r...@panix.com> wrote:[color=green]
>> don provan wrote:[/color]
>[color=green][color=darkred]
>> > Right, which is the point: they *are* bundled up, they are *not*
>> > "layered".[/color]
>>
>> Even inside applications, there are usually identifiable layers. For
>> example, look at a typical terminal application for a PC. There is code
>> that deals with TCP connections, code that deals with telnet or ssh stuff,
>> and code that deals with emulating an ANSI-X3.64 (or whatever) terminal.
>> These map (more or less) to layers 5-7 (session, presentation, and
>> application).
>>
>> In a well-designed application, you can swap components around at each
>> layer without affecting the other layers. The choice of whether to emulate
>> a VT-100 or an ADM-5 terminal can be made without regard for whether you're
>> running telnet, ssh, rlogin, or whatever.[/color]
>
> Exactly my point.
>
> Also, the layered model is not supposed to represent *just* what
> applies to the IP stack. It's supposed to represent the whole
> networking subject matter.[/color]
You guys are confusing modularity for layering. The reason those
techniques you speak of work is because The Application interacts with
all those pieces in a defined way so they can be swapped out. Layering
has the additional property that accessing a lower layer must be done
through any intervening layers even though the intervening layers have
absolutely nothing to do with -- and have no *reason* to have anything
to do with -- the lower layer that The Application needs to interact
with.
So, to give a concrete example, let's take the presentation "layer",
which formats data for network transmission. Since it's between the
application layer and the session, transport, and network layers, you
have to teach presentation layer all about opening and closing
connections, identifying peers, establishing network locations, for no
good reason other than that the OSI model says presentation is a
"layer". That's why, as I say, when the OSI protocol designers
actually got around to designing how application protocols worked,
they just discarded the OSI model as useless and implemented it as
functional blocks that could interact with each other as appropriate
rather than through a pointless and wasteful layering regime.
-don
Re: Does socket represent an interface between ... ?
On Jun 16, 6:14 pm, don provan wrote:
[color=blue]
> The Application interacts with
> all those pieces in a defined way so they can be swapped out. Layering
> has the additional property that accessing a lower layer must be done
> through any intervening layers even though the intervening layers have
> absolutely nothing to do with -- and have no *reason* to have anything
> to do with -- the lower layer that The Application needs to interact
> with.
>
> So, to give a concrete example, let's take the presentation "layer",
> which formats data for network transmission. Since it's between the
> application layer and the session, transport, and network layers, you
> have to teach presentation layer all about opening and closing
> connections, identifying peers, establishing network locations, for no
> good reason other than that the OSI model says presentation is a
> "layer".[/color]
I don't get this. On the contrary, I would say that you teach that
encoding or decoding the way parameters are presented is done the same
way, no matter what data link layer you use, no matter what network
layer you use, etc. For an incoming MS Word file, the way you decode
the parameters coming to your MS Word application does not depend on
whether the file was received over IP/Ethernet or over IPX/LANE/ATM.
Ditto in the opposite direction. And, of course, you can't read an
incoming Word file if you haven't gone through the presentation layer
before reaching the user.
BTW, in the drivetrain analogy, if the drivetrain is purely electric,
the functions of "transmission" and "differential" still apply,
although they are not performed with mechanical gears.
The electric motor(s) need to accommodate widely varying wheel speeds
efficiently, using means like coil shunting at high speeds, perhaps.
And you have to allow the inner and outer wheels to rotate at
different speeds in turns, so your motor controller cannot feed the
same voltage and current to each wheel (assuming separate motors in
each wheel).
So the conceptual model holds. I think the truth is that experienced
network designers understand the layered model intrinsically, without
letting it tie them up in knots trying to make it fit their specific
problem.
Bert
Re: Does socket represent an interface between ... ?
Albert Manfredi <bert22306@hotmail.com> writes:
[color=blue]
> I don't get this. On the contrary, I would say that you teach that
> encoding or decoding the way parameters are presented is done the same
> way, no matter what data link layer you use, no matter what network
> layer you use, etc.[/color]
Again, this is modularity, not layering. Look at it the other way:
suppose we discover something *new* to add to networking layer, an
entirely new function. If presentation is a module, it has nothing to
do with this, end of story. If presentation is a *layer* between
application layer and the lower layers, you have to teach presentation
layer about the entirely new function just so you can communicate the
necessary information from the application that wants to use the new
function to the networking layer that knows about the new function.
That's just an easy way to see the logical problem. In practice, there
are a wide range of negative effects of making presentation a "layer",
including the fact that you essentially have to teach presentation
layer your entire protocol so it knows which parts to encode in which
ways. Try to combine *two* protocols working together over the same
connection -- the kind of think OSI upper layers were built for -- and
you can see that things are really going to get complicated. If,
instead, you put presentation on the side as a function that can be
called to get the correct encodings for the correct parts of the
communications *before* the information leaves application layer,
things become much easier. This is, in fact, exactly what OSI upper
layer protocols ended up doing, but no one ever went back and
corrected the OSI model to remove the mistake.
[color=blue]
> For an incoming MS Word file, the way you decode
> the parameters coming to your MS Word application does not depend on
> whether the file was received over IP/Ethernet or over IPX/LANE/ATM.
> Ditto in the opposite direction. And, of course, you can't read an
> incoming Word file if you haven't gone through the presentation layer
> before reaching the user.[/color]
So how did presentation layer know it was a word file when that
information is passed in the application layer?
[color=blue]
> So the conceptual model holds. I think the truth is that experienced
> network designers understand the layered model intrinsically, without
> letting it tie them up in knots trying to make it fit their specific
> problem.[/color]
Absolutely. Of course, they have to stop and argue about it with the
kids out of school that insist ARP is a network layer packet....
-don
Re: Does socket represent an interface between ... ?
"don provan" <dprovan@comcast.net> wrote:
[color=blue][color=green]
>> For an incoming MS Word file, the way you decode
>> the parameters coming to your MS Word application does not depend on
>> whether the file was received over IP/Ethernet or over IPX/LANE/ATM.
>> Ditto in the opposite direction. And, of course, you can't read an
>> incoming Word file if you haven't gone through the presentation layer
>> before reaching the user.[/color]
>
> So how did presentation layer know it was a word file when that
> information is passed in the application layer?[/color]
Okay, now I understand what your objection is.
We agree, as things turned out, the session and presentation layers are
bundled with the application. So yes, the application has to be
identified before the file can go through the presentation layer (which
is now bundled in there with the application software).
In principle, it wouldn't have had to be this way. In principle, all
applications *could* have been written to a common presentation layer.
But of course, as you point out, that introduces its own disadvantages
when an application writer wants to innovate.
I see this as a minor inconvenience to the model, though. So we should
stick a shim just under layer 5 that says "app ID." The code to handle
session and presentation functions is still there, but it's potentially
different in different application software. But yes, IMO those layers
are still being traversed before you reach the GUI.
I see this as being a case of "when you're fluent in a language, you can
take certain liberties with its vacabulary and grammar."
[color=blue]
> Try to combine *two* protocols working together over the same
> connection -- the kind of think OSI upper layers were built for -- and
> you can see that things are really going to get complicated.[/color]
Why wouldn't this work much like separate byte streams are identified
through separate, simultaneous TCP sessions now? A common presentation
layer would be able to keep streams open from multiple sessions at the
same time. In principle. Even today, you can keep multiple applications
open at the same time, even if they are the same application.
Bert
Re: Does socket represent an interface between ... ?
"Albert Manfredi" <albert.e.manfredi@nospam.com> writes:
[color=blue]
> In principle, it wouldn't have had to be this way. In principle, all
> applications *could* have been written to a common presentation layer.[/color]
That's another element of the OSI model's problem: the OSI model tells
us that all applications *have to be* written to one single common,
monolithic presentation layer. Seeing presentation in the proper role
as a functional block allows the choice of applications sharing a
presentation function or using independent presentation functions.
And this, in turn, starts to get at the *real* problem with the OSI
model, which is it presents a picture of the network just as OSI
envisioned it: as a single, monolithic solution. It discourages
considering exactly the flexibility that makes the internet what it
is. The very fact that the layers had to support fixed, predefined
interfaces makes true innovation nearly impossible.
[color=blue]
> I see this as a minor inconvenience to the model, though.[/color]
You see it as a minor inconvenience. I see it as the model being
entirely wrong in a small way. The reason I think my view is more
reasonable is that the model cannot ever be fixed by adding anything
it doesn't already have, such as shims or an "app ID".
[color=blue]
> I see this as being a case of "when you're fluent in a language, you
> can take certain liberties with its vacabulary and grammar."[/color]
The OSI model isn't really very useful for people that are fluent, so
this is something of a non sequitar.
[color=blue][color=green]
>> Try to combine *two* protocols working together over the same
>> connection -- the kind of think OSI upper layers were built for -- and
>> you can see that things are really going to get complicated.[/color]
>
> Why wouldn't this work much like separate byte streams are identified
> through separate, simultaneous TCP sessions now?[/color]
Because the OSI model tells us to have a single connection. If you
have two connections, you've got two different applications, not two
application layer protocols interacting for the benefit of a single
application. (I'm being a little simplistic, mainly because I can't
really remember exactly what the OSI model says about it, but I stand
by the point that the model at least suggests the shared connection
approach, even while I admit not remember whether it actually allows
for multiple, cooperating connections between cooperating application
layer peers. I suppose I should pull out the model and read it again
if we're going to get into these details....)
-don provan
