Re: counted strings

gah4 <gah4@u.washington.edu>
Sat, 11 Jun 2022 13:53:44 -0700 (PDT)

          From comp.compilers

Related articles
counted strings christopher.f.clark@compiler-resources.com (Christopher F Clark) (2022-06-11)
Re: counted strings gah4@u.washington.edu (gah4) (2022-06-11)
| List of all articles for this month |
From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Sat, 11 Jun 2022 13:53:44 -0700 (PDT)
Organization: Compilers Central
References: 22-06-034
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="13005"; mail-complaints-to="abuse@iecc.com"
Keywords: lex, history, comment
Posted-Date: 11 Jun 2022 19:35:05 EDT
In-Reply-To: 22-06-034

On Saturday, June 11, 2022 at 6:58:14 AM UTC-7, Christopher F Clark wrote:
> I'm sorry for bringing more heat than light to this group.
>
> Counted strings are important for protocols. Not everything we write
> a lexer for is human written. Counted strings are a good way of
> transmitting binary data. This is just one way computers are
> different than humans....


Someone thought about that before. RPC, as used for NFS and
some other protocols, started with UDP, which has a record
boundary. It was later ported to TCP, which does not.


https://www.rfc-editor.org/info/rfc1831


So, section 10 describes the way records are marked.
They can be done in sections, so one doesn't have to buffer
the whole thing, or even know the whole length, to send
(or receive) one.


A similar method is used by IBM's VBS (Variable Blocked
Spanned) record format from OS/360 days, and still in
newer OS. It was originally needed for Fortran unformatted
I/O, but is part of the OS, and can be used by others.
(Especially, PL/I can read/write it.)
[RPC just has a length and a flag saying whether it's the last chunk. Internal
data are XDR which is fixed length with no counts or descriptors, pretty pessimal


-John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.