Media-tangle w.r.t. D80

Media-tangle has two formal nets for presenting (findable & modifiable) information.

Both nets reflect the data-communications, w.r.t. D80 -- as well as the state of the [local] databases. I mildly modify those from what D80 had discussed, to optimize them for Media-tangle.

The zoom menu is as if "only cosmetics", because that is not for watching the roaming token, but then again, that is probably right for a Petri net, because people mostly run static/batch tests with Petri nets, rather than interact (nor watch) their deterministic token games.

The zoom menu shape, is hinting the structure of the (transactions of the) Media-tangle system, while the list of 0xAF-media is for informing moment-by-moment.

Reflecting on those, may facilitate your understanding of the related issues in data-communications.

A request that is Afferent, if with a Favor from the fountain, will fire up the first row.

Following that, is the row for feedback,

• Reply to the request -- if not to repulse "rudely", closing the link
• Maintain the Media-tangle -- (local & remote) informazing/databases

For gathering the data, mediating is not limited to the (local) fountain. The media-tangling is there, for informaze strategies, too. But, for yet, as of Media-tangle 0.0a, that is not available.

The zooming figure is half-height, w.r.t. the four-row figure 9.b (p.636) of D80.

The 0xAF-media (the 175 visible ZIPs) are, w.r.t. the fig.13 (p.639) of D80.

from 1980

D80 is on data-transmission (send/receive data). Just what HTTP (web-serving) is.

I favor popularizing that paper published in 1980, to point out a case of plagiarism, in 1982 -- copycat82 is no study of any new "level". (For example, no load-balancing, nor availability issues.)

A "high-level" protocol (such as HTTP) is no different than a "low-level" protocol (such as the TCP/IP transport/network), if all functionality is simply to send-&-receive data.

If your interest is in formal-net tinkering, the software frozen@mid80 is more direct -- while Media-tangle is a mazing (internet application) software, with a formal-net style of interactivity.

is the fig9b all right?

D80 publishes the fig.9.b, only to next point out how that "IM" has shortcomings (p.636). But here, that is all right.

• The HTTP protocol is (conceptually) half-duplex any way, responding after a request is complete.
• The Media-tangle IM shows the stubs local to a fountain -- relating a request to the fountain-facilities.

persistent connections

With the HTTP/1.1 (rfc2616) favoring persistent-connections (that was available for HTTP/1.0, too, with the Keep-Alive option). We go full-duplex. That is, while we write out the response to the previous request, the following request is interpretable. To do this, mostly, fig9b is quite satisfactory again, because WinSock, the networking facility of Windows, is buffering that input. Thus, merely not closing the connection, is optimizing a lot. Immediately after the output finishes, we may continue interpreting the following bytes from that buffer.

pc & pipelining big files

In cases such as big file-submission request, following big file-retrieval request, we would not like to have that kind of interlock/loop as fig9b has, because they may safely run at the same/overlapping time period. But while using Petri nets, if we get rid of that interlock, that would allow the next request to run past the previous, because Petri net transitions do not wait even if there is a token in the destiny.

The fig13 is with Nutt style of formal-nets. Nutting is almost how a Petri net is, but tokens do not co-exist. That is all right, for showing the Media-tangle dynamics. While f(R) or f(M) may still keep writing the response to the previous request, f1 may interpret the next request.

is the fig13 all right?

The repetitive pattern of five cirles, (w.r.t ), in Media-tangle, reflect the media of the local fountain.

The fig13 of D80 is closely reflected in a medium figure, with a few changes.

• not X-transition, but J-transition is used (but following the mechanism of that X-transition)
• thus, the "0-vs-1" is now traveling in the token-attribute. The token-tag (w.r.t. D80), is the combo of the request-method (GET, HEAD, POST, PUT, etc) & the evolving status-code (200, 100, 404, etc.)

I use a J-transition, rather than the X-transition that D80 had published, because the output is through a single channel. That is, if I were to fork that with X-transition, I would have to merge the paths again, with a Y-transition.

That is a problem of pipelining, in persistent connections.

That is, for not facing two-R ("R0 & R1"), nor two-M ("M0 & M1") streams, at the output. Not to mix up the output bytes of the two "alternative" paths. For example, if the consecutive requests, one is all right, the other is a fault, they could mess, if both might write their outputs, concurrently.

Thus, we have to synchronize the two. Having a J-transition rather than that X-transition, is a remedy.

Fig 9b does not have that problem, because of that (potentially wasteful) interlock/loop that is not allowing the fountain to accept further requests, while the fountain has not finished the previous.

old friend, the Q-macro of NN73

Fig13, or theFive, is not optimal, yet. To optimize, I "modify" that (trivially) with queues without changing the system logic. That is, with the Q-macro (queue location) of NN73 (see frozen@mid80), after f1 (to f2), and two queues after f2 (to f(R) & f(M)). If all would take equal amounts of input & output time, queues would be useless.

As the HTTP requests may differ wildly in input-vs.-output intensiveness, to relax the tension is valuable.

Thus, if a request is input-intensive, keeping f1 busy more than f(R), while other request is output-intensive, causing f(R) to take time, the queue from f1 to f2, in the middle, is smoothing that tension out. That is, input & output intensives do not have to work at lockstep, the slowest sum.

If all the time, f(R) & f(M) would have equal amounts of output to do, there would be no need to have queues after f2, but for smoothing out their statistical deviations, I'm buffering there, too.

looping-within -- safely & conservatively

D80 was interested in Nutting, for keeping the control-graph small -- thus, cutting the test-cost, & less tedious.

In that sense, or little different, the f1, f(R), & f(M) may loop for a time, getting (asynchronous) input/output messages from the platform -- the Windows Sockets FD messages for available input/output.

In programmatic shortcut, re-running a transition-function (message loop) until that flags "finish".

The Petri net token-game is not altered, because the tokens keep where they are, until that transition flags the "finish". (Straightforward to show the equivalent control-graph/macro.)

pc & big files & 100

What if a request expects the HTTP "100-continue" message? If the request wants that, the server has to respond with "100" -- if not a fault. (The fault-report opposing a "100" request is like the normal fault cases.)

The waiting for "100", is probably not optimal, locally, but if the request was right in guessing the risk of refusal, not having sent the bigfile without "100" may have saved the network-bandwidth.

That is the rfc2616 strategy. The point is like that of environmental issues. Bandwidth is for all.

If f1 hides that 100:

• To respond with that interim "100", the f1 that is supposedly for input-only has to output, too
• if there is output activity in f(R), the transition after R, then f1 has to sleep for all output to finish
• f(R) wakes f1 up, after finishing
• f1 sends that "100"ful output, to continue getting the rest of the bytes of the request that will come.

Totally getting rid of internal flagging is doable, too -- for example, if we want only f(R) to do output.

Looping with F (as with the looping-within, but with extra X-transition that sends a "100" message to f(R)), is enough. A turns off, until the request continues with new input -- after f(R) sends "100".

to hide that 100 is right?

Fig9b two-row intermediate section that I left out, would correspond to the (optional) intermediate expect-100 of HTTP. Media-tangle is automatically sending that expected 100. A human is not needed for interacting with.

No sense to show that in the zoom. Therefore, the two-row figure that I draw, is enough.

Fig13, with f1 hiding 100, is all right. A fine example of abstracting-a-control-graph, that is, guaranteed,

• without deadlock. Only f1 may sleep, waken up by only f(R)
• the control path is fixed from f1 to f(R) -- w/o external interrupts in between
• output bytes go out in the expected order. The front transition is waking the behind up.

Thus, not showing the case for "100" explicitly, is a faithful summary of the full graph.

As I have said a lot, the control-graph has to show all of the critical control logic! The ignorance of copycat82, in assuming that a semaphore would not matter, has no link to the riskless way I use.

informative flashes

The location A is on while f1 of that medium is looping (getting/waiting for input) for a request to finish.

The location F is on, as long as the medium is friendly. That is f1 is working for that friend, or willing to.

The location at the middle is normally too fast to see, but if the queues for R or M, is/are full, that may be.

The location R is on while output, in response to the request -- visible if the output file is too long.

The location M is the Media-tangle feedback time.

the zoom w.r.t. the five

D80 was discussing the list of different-but-functionally-related formalisms (& in case study), that I may relate to.

The two-row zoom figure, is showing the structure of the HTTP request & response. If to reflect,

• w.r.t. fig9b of D80, they are the first, & the last transitions.
• w.r.t. fig13 of D80, they are f1, & the combo of transitions that f2 is feeding into -- the f(R) & f(M)

This set of figure-equivalences are visibly tellable, the way I label the zoom, & the five. The token-list, A, F, & R in the two figures correspond. The M may correspond, too, if the data is served from the local fountain, but in other cases, the fig9b is (as if) not reflecting the final phases of reporting to the informing media-tangle links.

That is why the zoom figure has the third outgoing arrow there, not existing in fig9b. The fig9b would suggest that feedback to be in the next turn, while getting info for the next request. But, f(M) may talk with different media (two or more), too. Thus, to feedback immediately, is called for.

In summary, the zoom is for interacting with the [local] fountain-facilities -- for example, for zooming into the history logs, & fountain policies. The five is reflecting the immediate dynamics of the continuing transactions.

0xAF is 175, in hexadecimal. For most of us, having at most 175 (0xAF) of those, is no shortage.

The 0xAF0 (2800), or 0xAF00 (44800) Media-tangle is thinkable, too. But for watching, I would have to summarize those in a room hierarchy. I postpone that, for watching only theFive.

I had written (PSY) software, with data-hierarchies/summarizing, those I had written in 1991 to 1994, are there. Hypothesis/test statistics, person-based statistics, & point-by-point data.

We could allow theFive to pipeline the peer-list, just as the request-list from a single peer is pipelined. That would have more work, with only 0xAF media, because the closing job-list does not keep the front two, A & F, of that medium busy. But that is not optimal, because if the "closing" that is running at f(R) & f(M) will take huge time (cf. downloading a huge .zip file). The new peer-list would (probably) wait behind that idly (unless they are input-intensive). If the system is that busy, having 0xAF0, or 0xAF00 media, is the right (& trivial) remedy.

a tangle (of plural), as a single

Rather than the single global medium that D80 had shown, we have our Media-tangle -- for filtering/routing.

That is what networking is. In formal work, to abstract was useful, as D80 did. In networking with people, we refine that back again, to allow forming a human-guided network -- with informaze.

cf. A transport packet may correspond to multiple lower-level packets [hopping multiple nodes].

A Petri net with token-attributes -- representing a (favor for) flow of information.

With modules as fig9b/fig13. The fountain (zoom) is the same for all such, but any of the 0xAF-media (the local stubs), may be within various informazing media throughout internet. That is, the word "media" may be in the sense of the local media (stubs), or the forming internet-wide media. (The word media is the plural of medium.) The local media, thus, may be facilitating 0xAF informazing transactions(or, more, with hierarchies & caching).

A figure (w.r.t. fi9b/fig13) is what is immediately known within just one fountain/medium, in a Media-tangle.