9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: I RATTAN <rattan@cps.cmich.edu>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Cc: russcox@gmail.com
Subject: Re: [9fans] 9p2000 query
Date: Fri, 13 May 2005 16:55:04 -0400	[thread overview]
Message-ID: <Pine.GSO.4.58.0505131646310.25968@cps211.cps.cmich.edu> (raw)
In-Reply-To: <77ea6b7c9988149c674429387f842122@plan9.ucalgary.ca>

Here is rephrasing:

server process om machine X is servicing tokens to clients (run on
other machines):

client on A sends a request (message), wsits for reply to come back
can server process pickup the request with single read operation
(assume that a connection has been set up between client and
server processes)?

scenarios possible here:
- one can use tcp from tcp/ip (it is there under Plan 9)
- one can use udp from tcp/ip (is it available under Plan 9)
- one can use 9P without worrying about the underlying protocol(s)
  as it will provide guaranteed service??

-ishwar

On Fri, 13 May 2005, andrey mirtchovski wrote:

> > or no, depending on the file server.
> > it's not really a well-formed question now that i think about it.
> >
> > devpipe preserves message boundaries.
> > il does too.
> > tcp does not.
> >
>
> "Plan 9 from Bell Labs" discusses message boundaries briefly in the
> context of 9p:
>
> "The 9P protocol must run above a reliable transport protocol with
> delimited messages.  9P has no mechanism to recover from transmission
> errors and the system assumes that each read from a communication
> channel will return a single 9P message; it does not parse the data
> stream to discover message boundaries.  Pipes and some network
> protocols already have these properties but the standard IP protocols
> do not.  TCP does not delimit messages, while UDP [RFC768] does not
> provide reliable in-order delivery."
>
> those may not be the same message boundaries Ishwar was looking for
> though.
>


  parent reply	other threads:[~2005-05-13 20:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-13 18:21 I RATTAN
2005-05-13 20:02 ` Russ Cox
2005-05-13 20:04   ` Russ Cox
2005-05-13 20:14     ` andrey mirtchovski
2005-05-13 20:45       ` Brantley Coile
2005-05-13 20:55       ` I RATTAN [this message]
2005-05-13 21:09         ` Ronald G. Minnich
2005-05-13 21:48     ` "Nils O. Selåsdal"

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.4.58.0505131646310.25968@cps211.cps.cmich.edu \
    --to=rattan@cps.cmich.edu \
    --cc=9fans@cse.psu.edu \
    --cc=russcox@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).