[9fans] Client/server program sample code request..

[9fans] Client/server program sample code request..

[Ish Rattan]

Where can I find a client/server (simple service like echo service)
using 9P?

- ishwar

Re: [9fans] Client/server program sample code request..

[andrey mirtchovski]

On Thu, 21 Sep 2000, Ish Rattan wrote:

> 
> Where can I find a client/server (simple service like echo service)
> using 9P?

try 'man 2 dial'

AFAIK the announce() and dial() calls work with 9P as well as with tcp...

Re: [9fans] Client/server program sample code request..

[andrey mirtchovski]

argh.. scratch that.. 

s/9P/il/g :)

On Thu, 21 Sep 2000, andrey mirtchovski wrote:

> 
> try 'man 2 dial'
> 
> AFAIK the announce() and dial() calls work with 9P as well as with tcp...
> 
> 
> 

Re: [9fans] Client/server program sample code request..

[rog]

> > Where can I find a client/server (simple service like echo service)
> > using 9P?
>
> try 'man 2 dial'
>
> AFAIK the announce() and dial() calls work with 9P as well as with tcp...

actually, announce() and dial() make network connections; 9p is a
protocol that runs on top of a network connection.

a service implemented with 9p is presented as a file tree.  to
implement one you have to decide what you want the file tree to look
like. a simple, static set of files is easiest to implement. see 9p(2)
for a library that facilitates implemention of 9p servers.

perhaps you meant "il" (the preferred LAN protocol for 9p), in which
case, the programming is exactly the same as for tcp or udp (use
announce() or dial()) except substituting "il" for "tcp" or "udp" in
the address string.

  cheers,
    rog.

Re: [9fans] Client/server program sample code request..

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 209 bytes --]

not really what you're looking for, but worth pointing out anyway:

term% grep echo /lib/ndb/common
tcp=echo port=7
il=echo port=7
udp=echo port=7

term% cat /rc/bin/service/il7
#!/bin/rc
/bin/cat


[-- Attachment #2: Type: message/rfc822, Size: 1595 bytes --]

From: Ish Rattan <ishwar@pali.cps.cmich.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] Client/server program sample code request..
Date: Thu, 21 Sep 2000 11:43:30 -0400 (EDT)
Message-ID: <Pine.BSF.4.21.0009211141270.19085-100000@pali.cps.cmich.edu>


Where can I find a client/server (simple service like echo service)
using 9P?

- ishwar

Re: [9fans] Client/server program sample code request..

[Boyd Roberts]

From: <forsyth@caldo.demon.co.uk>

> not really what you're looking for, but worth pointing out anyway:

neither is this, 'cos it's written in limbo, but if you have the vita nuova
cd
you could build a simple pop client [each message in a file] out of it:

    http://www.planete.net/~boyd/code/pop.bundle

dial() is just _so_ much better than that ghastly bezerkley socket
interface.

Re: [9fans] Client/server program sample code request..

[Steve Kilbane]

Boyd wrote:
> dial() is just _so_ much better than that ghastly bezerkley socket
> interface.

It is, true. I do wonder, though, how much of the mess vs. cleanliness
difference came about because much of the common uses of networks had
settled down a lot by the time Plan 9 first came into existence.
I.e, were the BSD lot trying to solve predicted problems that came to
be irrelevant to 99.99% of people writing network code?

steve

Re: [9fans] Client/server program sample code request..

[Tom Duff]

On Sep 22,  7:40am, Steve Kilbane wrote:
> Boyd wrote:
> > dial() is just _so_ much better than that ghastly bezerkley socket
> > interface.
>
> It is, true. I do wonder, though, how much of the mess vs. cleanliness
> difference came about because much of the common uses of networks had
> settled down a lot by the time Plan 9 first came into existence.
> I.e, were the BSD lot trying to solve predicted problems that came to
> be irrelevant to 99.99% of people writing network code?

There was some talk about this when wnj was designing the
BSD socket code, and I think it's fair to say that he had
his mind made up, and did pretty much what he wanted.

-- 
Tom Duff.  I'm not running for anything, so I can answer honestly.

RE: [9fans] Client/server program sample code request..

[Stephen Parker]

> actually, announce() and dial() make network connections; 9p is a
> protocol that runs on top of a network connection.

is there a protocol that's been commonly used for carrying 9p/styx over
serial lines?

i quite fancy attaching some (small) embedded devices to plan9/inferno
and don't want the complexity of ppp yet need a reliable service.
anything recommended?

thanks,
stephen

Re: [9fans] Client/server program sample code request..

[Russ Cox]

I think that, at least at the C interface level,
the sockets problem stems mainly from trying
to solve everything in C rather than with a 
(very) little language like the dial strings.
I'm not up on my history of which came first, 
but the dial strings were in Research Unix
too.

A more vivid example of this distinction is the 
difference in usability between an embedded
Tk for Limbo or C, which just provides a
function tkcmd(char*) to which you pass Tk
syntax, and a purely extant-language-based
solution like GTK+, in which all the elegant
Tk syntax is lost to clumsy C or C++ expressions
because someone was (probably unnecessarily)
worried about efficiency.

Russ

Re: [9fans] Client/server program sample code request..

[Dan Cross]

In article <20000922182142.4DD31199D0@mail> you write:
>I think that, at least at the C interface level,
>the sockets problem stems mainly from trying
>to solve everything in C rather than with a 
>(very) little language like the dial strings.
>I'm not up on my history of which came first, 
>but the dial strings were in Research Unix
>too.

I never did really understand this.  It seems like Joy
was the kind of guy who ``got it,'' so why did he make
such a nasty decision?  To be sure, the ``Network UNIX''
RFC was a much saner design for the ARPAnet, and was
available around the time the Berkeley folks were doing
sockets.  It seems what they did goes against everything
that Unix stood for at that time.  It's especially weird
since Joy did well with other things in the ``little
language'' department (eg, termcap).

>A more vivid example of this distinction is the 
>difference in usability between an embedded
>Tk for Limbo or C, which just provides a
>function tkcmd(char*) to which you pass Tk
>syntax, and a purely extant-language-based
>solution like GTK+, in which all the elegant
>Tk syntax is lost to clumsy C or C++ expressions
>because someone was (probably unnecessarily)
>worried about efficiency.

Amen.  Too much concern for efficiency drives
software bloat.  Ironically, it usually has the
effect of making the software significantly
less efficient.

	- Dan C.

Re: [9fans] Client/server program sample code request..

[Boyd Roberts]

----- Original Message -----
From: "Dan Cross" <cross@math.psu.edu>
>
> I never did really understand this.  It seems like Joy
> was the kind of guy who ``got it,'' so why did he make
> such a nasty decision?

joy never understood anything.  he'd have some half baked idea
over the weekend and it'd be implmented (badly) sooner or later.

you know why the BSD file-system was implemented?  another
half baked joy idea, given to kirk, because his funding
had run out.

vi:  goto fonfon.  consider how ~ works.  it reads the current char and
forces
     rCl back on input -- where C is the opposite case.  hence you can't go
10~.

csh: && and || worked the wrong way round.

> It's especially weird
> since Joy did well with other things in the ``little
> language'' department (eg, termcap).

little?  unmitigated catastrophy.

> Amen.  Too much concern for efficiency drives
> software bloat.  Ironically, it usually has the
> effect of making the software significantly
> less efficient.

nonsense:  don't diddle the code, choose a better algorithm.

Re: [9fans] Client/server program sample code request..

[presotto]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

Dial is actually from research Unix.  Wnj and Sam Leffler were doing
the socket stuff while I was at UCB.  It was not bad considering
they were starting from scratch and other interfaces were just
as awkward.  Binary addresses didn't seem so bad when all
addresses were 32 or 48 bit numbers.  However, I couldn't ever
remember how to do anything and always got the dance wrong.
It also had a bad effect of making every program very network
and often byte order specific.

When I came to the labs, research Unix was using the Datakit
network instead of ethers and IP (we bell heads spent a long
time denegrating ethernets and IP before were beaten into
submission but that's another story).  Datakit
used relative hierarcical string addresses (things like
"mh/astro/r70").  They already were using a dkdial() call
that looks pretty much like the dial() in Plan 9.  The interface
for datakit was file system based, also very much like the Plan 9
one is now.  When rtm ported the 4.1c BSD IP code into research Unix,
we adopted the datakit model rather than sockets because it was,
we thought, easier to deal with.

The Plan 9 interface is just a continuation along the same lines.

Thank Lee McMahon, Sandy Fraser, and Greg Chesson for the nicer
model that came with the Datakit.  We just recognized the elegance
of their work and expanded it.  At a programming interface level, that can
be said of Plan 9 in general.  Research Unix experimented and Plan 9
generalized.  Similarly, Rob's Blit work was the seed for the Plan 9
look and feel user interface look and feel.  The only things original
are the maleable process specific name space and the implementation.

[-- Attachment #2: Type: message/rfc822, Size: 2344 bytes --]

From: "Tom Duff" <td@pixar.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Client/server program sample code request..
Date: Fri, 22 Sep 2000 10:18:39 -0700
Message-ID: <10009221018.ZM25618@marvin>

On Sep 22,  7:40am, Steve Kilbane wrote:
> Boyd wrote:
> > dial() is just _so_ much better than that ghastly bezerkley socket
> > interface.
>
> It is, true. I do wonder, though, how much of the mess vs. cleanliness
> difference came about because much of the common uses of networks had
> settled down a lot by the time Plan 9 first came into existence.
> I.e, were the BSD lot trying to solve predicted problems that came to
> be irrelevant to 99.99% of people writing network code?

There was some talk about this when wnj was designing the
BSD socket code, and I think it's fair to say that he had
his mind made up, and did pretty much what he wanted.

-- 
Tom Duff.  I'm not running for anything, so I can answer honestly.

Re: [9fans] Client/server program sample code request..

[Boyd Roberts]

datakit:

    not known to work reliably at any speed, but the code is huge

:-)

Re: [9fans] Client/server program sample code request..

[Dennis Ritchie]

presotto@plan9.bell-labs.com wrote (I snip a lot):
> 
> Dial is actually from research Unix.  Wnj and Sam Leffler were doing
> the socket stuff while I was at UCB.  It was not bad considering
> they were starting from scratch and other interfaces were just
> as awkward...

> When I came to the labs, research Unix was using the Datakit
> network instead of ethers and IP (we bell heads spent a long
> time denegrating ethernets and IP before were beaten into
> submission but that's another story).  Datakit
> used relative hierarcical string addresses (things like
> "mh/astro/r70").  They already were using a dkdial() call
> that looks pretty much like the dial() in Plan 9.  The interface
> for datakit was file system based, also very much like the Plan 9
> one is now.  When rtm ported the 4.1c BSD IP code into research Unix,
> we adopted the datakit model rather than sockets because it was,
> we thought, easier to deal with.
> 
> The Plan 9 interface is just a continuation along the same lines.

In case you don't recognize the "rtm"-- for historical completeness,
it is Robert Tappan Morris.

The roots of the approach are clearly exposed in
 http://cm.bell-labs.com/cm/cs/who/dmr/ipcpaper.html
by Dave and me.  He did more of the work, as usual.
The underlying ideas go back a long way.

> 
> Thank Lee McMahon, Sandy Fraser, and Greg Chesson for the nicer
> model that came with the Datakit.  We just recognized the elegance
> of their work and expanded it.

Indeed.  From the application level, the main difference between the
original UCB socket approach and the one that grew in the Plan 9 scheme
is that network names should be textual and visibly hierarchical,
and translated into raw network addresses by a mechanism that isn't written
or compiled into every program that uses them.  Sort of like DNS.  Also,
that I/O over a network connection should be made to look like other I/O
to the extent possible.   Dealing with two network technologies simultaneously
(Datakit vs. Ethernet->Internet + TCP/IP) helped push the generalization.

	Dennis

Re: [9fans] Client/server program sample code request..

[presotto]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

Depends on what code you're taking about.  The datakit code in research
Unix was a fraction of the size of our IP stacks.  The code
that ran on the datakits themselves was larger but still a tiny
fraction of the size of CISCO's IOS or, the equivalent at that time,
a Unix machine being used as a router.

If you're comparing Datakit to Ethernet, then you're right.
I, however, tend to compare Datakit to IP.  Both ran on a number
of media and provided transport level protocols with defined
services.

Our datakit nodes were definitely not the worlds most reliable
LAN's.  If you compare against IP running on an Ethernet, then
a coax is certainly a lot more reliable than a Datakit node with
an interface for each host.  However, as a WAN, our network was
a lot more reliable than our equivalent IP networks whose
nodes were usually BSD Unix boxes with multiple interfaces
plugged in.  The latter had a bad habit of eating all their
MBUF's or crashing for a strangely large number of other reasons.

The host interface boards for both networks were similar in
reliability, i.e., crappy.   We lived with both Ethernet(carrying IP)
and Datakit plugged into the same machines for a long
time.  Having both networks definitely improved connectivity
over either one by leaps and bounds.  One of the reasons for
a general dial() routine was to try first one then the other.

As datakit development died off, its reliability fell way
behind that of IP, largely because routers got a lot more
reliable while datakit stayed the same.

Datakit died for a lot of good reasons; slow machine interfaces,
central control at a time autonomy was being exploited,
proprietary hardware and protocols, support by few
computer manufacturers, static routing, ...  I don't
believe that reliability was one of them.

[-- Attachment #2: Type: message/rfc822, Size: 1697 bytes --]

From: "Boyd Roberts" <boyd@planete.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Client/server program sample code request..
Date: Sat, 23 Sep 2000 04:51:03 +0200
Message-ID: <024a01c02509$1d40e720$89c584c3@cybercable.fr>

datakit:

    not known to work reliably at any speed, but the code is huge

:-)