On 03/12/2024 10:09 AM, Ross Finlayson wrote:
So, the usual abstraction of request/response,
and the usual abstraction of header and body,
and the usual abstraction of composition and transport,
and the usual abstraction of multiplexing mux/demux,
and the usual abstraction of streaming and stuffing,
and the usual abstraction of handles and layers,
in the usual abstraction of connections and resources,
of a usual context of attachments and sessions,
in the usual abstraction of route links and handles,
makes for a usual abstraction of protocol,
for connection-oriented architectures.
>
>
Hipoio
"Protocol" and "Negotiation"
The usual sort of framework, for request/response or
message-oriented protocols, often has a serialization
layer, which means from the wire to an object representation,
and from an object to a wire representation.
So, deserializing, involves parsing the contents as arrive
on the wire, and resultingly constructing an object. Then,
serializing is the complementary converse notion, iterating
over the content of the object and emitting it to the wire.
Here the wire is an octet-sequence, for a connection that's
bi-directional there is the request or client wire and response
or server wire, then that usual matters of protocol, are
communicating sequential processes, either taking turns
talking on the wire, "half-duplex", or, multiplexing events
as independently, "full-duplex".
So, the message deserialization and message composition,
result in the protocol, as about those get nested, what's
generally called "header and body". So, a command or
request, it's got a header and body, then in some protocols
that's all there is to it, while for example in other protocols,
the command is its own sort of header then its body is the
header and body of a contained message, treating messages
first class, and basically how that results all sorts of notions
of header and body, and the body and payload, these are the
usual kinds of ideas and words, that apply to pretty much all
these kinds of things, and, it's usually simplified as much as
possible, so that frameworks implement all this and then
people implementing a single function don't need to know
anything about it at all, instead just in terms of objects.
Protocol usually also involves the stateful, or session,
anything that's static or "more global" with respect to
the scope, the state, the content, the completions,
the protocol, the session, the state.
The idea then I've been getting into is a sort of framework,
which more or less supports the protocol in its terms, and,
the wire in its terms, and, the resources in their terms, where
here, "the resources" usually refers to one of two things,
the "logical resource" that is a business object or has an identifier,
and the "physical" or "computational resource" which is of
the resources that fulfill transfer or changes of the state of
the "logical resources". So, usually when I say "resources"
I mean capacity and when I say "objects" it means what's
often called "business objects" or the stateful representations
of identified logical values their lifecycle of being, objects.
So, one of the things that happens in the frameworks,
is the unbounded, and what happens when messages
or payloads get large, in terms of the serial action that
reads or writes them off the wire, into an object, about
that it fills all the "ephemeral" resources, vis-a-vis vis
the "durable" resources, where the goal is to pass the
"streaming" of these, by coordinating the (de)serialization
and (de)composition, what makes it like so.
start ... end
start ... first ... following ... end
Then another usual notion besides "streaming", a large
item broken into smaller, is "batching", small items
gathered into larger.
So what I'm figuring for the framework and the protocols
and the negotiation, is what results a first-class sort of
abstraction of serialization and composition as together,
in terms of composing the payload and serializing the message,
of the message's header and body, that the payload is the message.
This might be familiar in packets, as, nested packets,
and, collected packets, with regards to that in the model
of the Ethernet network, packets are finite and small,
and that a convention of sockets, for example, establishes
a connection-oriented protocol, for example, that then
either the packets have external organization of their
reassembly, or internal organization of their reassembly,
their sequencing, their serialization.
Of course the entire usual idea of encapsulation is to
keep these things ignorant of each other, as it results
making a coupling of the things, and things that are
coupled must be de-coupled and re-coupled, as sequential
must be serialized and deserialized or even scattered and
gathered, about then the idea of the least sort of
"protocol or streaming" or "convention of streaming",
that the parsing picks up start/first/following/end,
vis-a-vis that when it fits in start/end, then that's
"under available ephemeral resources", and that when
the message as it starts getting parsed gets large,
then makes for "over available ephemeral resources",
that it's to be coordinate with its receiver or handler,
whether there's enough context, to go from batch-to-streaming
or streaming-to-batch, or to spool it off in what results
anything other an ephemeral resource, so it doesn't
block the messages that do fit, "under ephemeral resources".
So, it gets into the whole idea of the difference between
"request/response" of a command invocation in a protocol,
and, "commence/complete", of an own sort of protocol,
within otherwise the wire protocol, of the receives and
handlers, either round-tripping or one-way in the half-duplex
or full-duplex, with mux/demux both sides of request/response
and commence/complete.
This then becomes a matter relevant to protocol usually,
how to define, that within the protocol command + payload,
within the protocol header + body, with a stream-of-sequences
being a batch-of-bytes, and vice-versa, that for the conventions
and protocols of the utilization and disposition of resources,
computational and business, results defining how to implement
streaming and batching as conventions inside protocols,
according to inner and outer the bodies and payloads.
The big deal with that is implementing that in the (de)serializers,
the (de)composers, then about that a complete operation can
exit as of start -> success/fail, while commence might start but
it can fail while then it's underway, vis-a-vis that it's "well-formed".
So, what this introduces, is a sort of notion, of, "well-formedness",
which is pretty usual, "well-formed", "valid", these being the things,
then "well-flowing", "viable", or "versed" or these automatic sorts
of notions of batching and streaming, with regards to all-or-none and
goodrows/badrows.
Thusly, getting into the framework and the protocols, and the
layers and granular and smooth or discrete and indiscrete,
I've been studying request/response and the stateful in session
and streaming and batching and the computational and business
for a long time, basically that any protocol has a wire protocol,
and a logical protocol above that, then that streaming or batching,
is either "in the protocol" or "beneath the protocol", (or, "over the
protocol", of course the most usual notion of event streams and their
batches), is that here the idea is to fill out according to message
composition, what then can result "under the protocol", a simplest
definition of (de)serialization and (de)composition,
for the well-formedness and well-flowingness the valid and versed,
that for half-duplex and full-duplex protocols or the (de)multiplexer,
makes it so possible to have a most usual means to declare
under strong types, "implement streaming", in otherwise
a very simple framework, that has a most usual adapter
the receiver or handler when the work is "within available
ephemeral resources", and falls back to the valid/versed
when not, all the through the same layers and multiplexers,
pretty much any sort usual connection-oriented protocol.
Hi-Po I/O
Re: Meta: a usenet server just for sci.math