"in the past [...] protocols were documented by bit-layouts of packets"
https://indico.esa.int/event/57/contributions/2701/attachments/2245/2598/Data_Modelling_with_ASN.1.pdf#page=4&zoom=auto,-278,13 ASN.1 compilers generate C code, though. > Date: Sun, 12 Mar 2023 14:56:58 -0400 (EDT) > From: "David P. Reed" <[email protected]> > To: [email protected] > Subject: Re: [Starlink] RFC: bufferbloat observability project (Dave > Taht) > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > > I should have added this: I am aware of a full TCP stack implementation > implemented in Verilog. (In fact, my son built it, and it is in production > use on Wall St.). > > On Sunday, March 12, 2023 2:51pm, "David P. Reed" <[email protected]> > said: > > > > Regarding unbounded queues > On Sunday, March 12, 2023 12:00pm, Dave Taht <[email protected]> said: > >> Also it increasingly bothers me to see unbounded queues in so many new >> language libraries. > > > I disagree somewhat. Unbounded queueing is perfectly fine in a programming > language like Haskell, where there are no inherent semantics about timing - > a queue is an ordered list with append, and it's a GREAT way to formulate > many algorithms that process items in order. > > Where the problem with queues arises is in finite (bounded) real-time > programming systems. Which include network protocol execution machines. > > It's weird to me that people seem to think that languages intended for > data-transformation algorithms, parsers, ... are appropriate for programming > network switches, TCP/IP stacks, etc. It always has seemed weird beyond > belief. I mean, yeah, Go has queues and goroutines, but those aren't > real-time appropriate components. > > What may be the better thing to say is that it increasingly bothers you that > NO ONE seems to be willing to create a high-level programming abstraction > for highly concurrent interacting distributed machines. > > There actually are three commercial programming languages (which are about > at the level of C++ in abstraction, with the last maybe being at the level > of Haskell). > 1. Verilog > 2. VHDL > 3. BlueSpec > > For each one, there is a large community of programmers proficient in them. > You might also consider Erlang as a candidate, but I think its "queues" are > not what you want to see. > > Why doesn't IETF bother to try to delegate a team to create such an > expressive programming language or whatever? I'd suggest that starting with > Verilog might be a good idea. > > A caveat about my point: I write Verilog moderately well, and find it quite > expressive for modeling networking systems in my mind. I also write Haskell > quite well, and since BlueSpec draws on Haskell's model of computation I > find it easy to read, but I've not written much Haskell. > > To me, those who write networking code in C or C++ are stuck in the past > when protocols were documented by bit-layouts of packets and hand-waving > English "standards" without any way to verify correctness. We need to stop > worshipping those archaic RFCs as golden tablets handed down from gods. > > Who am I to criticize the academic networking gods, though? _______________________________________________ Starlink mailing list [email protected] https://lists.bufferbloat.net/listinfo/starlink
