Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!zweig
From: zweig@p.cs.uiuc.edu
Newsgroups: comp.protocols.iso
Subject: Re: X-WINDOWS & OSI
Message-ID: <99600003@p.cs.uiuc.edu>
Date: 23 Jun 89 17:57:00 GMT
References: <5560025@hpindda.HP.COM>
Lines: 50
Nf-ID: #R:hpindda.HP.COM:5560025:p.cs.uiuc.edu:99600003:000:2535
Nf-From: p.cs.uiuc.edu!zweig    Jun 23 12:57:00 1989


> Written Jun  9, 1989 by collin@hpindda.HP.COM in comp.protocols.iso
> ---------- "Re: X-WINDOWS & OSI" ----------
>    [stuff omitted]
> I don't know of any good argument to increase the communications
> overhead of X-windows by requiring S/P/(and at connection-time, ACSE).
> If we don't try to call X an OSI application, then there's no need
> that I know of to require that it run in its "proper" place in the
> osi architecture.

Since X (according to what I've gleaned of its innards from talking with
X-hackers) already determines the sorts of things the presentation layer
is concerned with (byte-order, etc.) and basically _contains_ a session-layer
protocol, I don't think I understand the beef on this bone being picked.

Certainly 2 or 3 seconds of ACSE muddling when I open an x-session (assuming
a reasonably bad ACSE implementation) isn't going to be noticed, and once
we're connected the Presentation and Session layers are null.

There is a common misapprehension that "null" protocol layers involve
calling functions and telling them not to do anything and that this can
add substantially to the overhead of communication. Wrongo!

I can give you a half-dozen tricks (one in particular) that can enable a
module up in user space to talk directly to the transport mechanism, while
still "thinking" it's talking to the presentation layer. Delegate the
functionality and use pointers intelligently and null P/S means 0 runtime
overhead. It's not a problem.

The OSI layering is a _conceptual_ layering, not a software-architectural
layering. There's no reason at all that an application can't DMA right to
an ethernet board in an ISO/OSI compliant implementation, so long as the
application is written so that it "thinks" it's interacting with the
appropriate presentation-layer entities. More specifially, the person who
wrote the application-layer entity thinks he's dealing with what he thinks
the presentation layer is; maybe a compiler optimizes away the unnecessary
baggage.....

If you think 7-layers means 7 function calls, 7 buffer-copies, and a 
(Craig?) Partridge in a pear tree, somebody has told you some seriously
incorrect things.

-Johnny Zweig
 University of Illinois at Urbana-Champaign
 Department of Computer Science
--------------------------------Disclaimer:------------------------------------
   Rule 1: Don't believe everything you read.
   Rule 2: Don't believe anything you read.
   Rule 3: There is no Rule 3.
-------------------------------------------------------------------------------