asciilifeform: specifically in re 'iron built for reliability', 'tandem' was interesting. i dun expect to ever lay hands on 1 , tho
asciilifeform: lotsa ancient artifacts are imho worth documenting. tricky bit is getting at the surviving crumbs.
asciilifeform: e.g. xerox lispm is rarer still ( and had own merits, which i pieced together 100% from docs and surviving photos and won't even go into in depth because approx as questionable as archaeology of merv... )
asciilifeform: mircea_popescu: believe or not, bolix aint even the least-gettable old/interesting comp
asciilifeform: i gotta take to drink, so i can quit!11
asciilifeform: apparently quitting drink, does do ~sumthing~
asciilifeform: ( can laff if you like, at the d00d, but he ~does~ apparently have a blog. and it's even 1 that aint in 'lamp stack' , and i envy the pg load latencies.. )
asciilifeform: els and VMM’s still have code injections and leaks the 1990’s versions prevented. Recent example being cache-based, side channels originally reported in 1992 in VAX VMM using analysis method from 1991.' )
asciilifeform: meanwhile, for pro entomologists only, https://archive.is/UFTWQ ( e.g. 'Some like SNS Server have no reported breaches over almost 30 years. Companies wouldn’t buy them. FOSS folks don’t build them. To this day and uniquely to this sub-field, most folks well-known in security act like none of that work ever happened, ignore those methods that got results, and slowly reinvent them or knockoffs of them with less results. Their kern
asciilifeform: yea strike that. ( asciilifeform mistaken in >1 way, it is also possible for '9000' legit clients to issue hello and overfill , even if it were actually the case that 1:1 handshake )
asciilifeform: diana_coman: 2nd link in post (to asciilifeform's www) malformed
asciilifeform: mircea_popescu: from my reading, diana_coman will have same proggy on 2 boxen, but routine-a runs on box a, and routine-b on b
asciilifeform: why wouldja have an empty queue (unless no traffic) ..?
asciilifeform: + priorityqueues dun have O(1) insertion.
asciilifeform: ( item can be made as mircea_popescu described, either from 2 fifos or 1 priorityqueue. but the latter is actually much moar complicated, in re moving parts, than the former )
asciilifeform: what happens is that nothing behind the 22 rsa items is eaten until they are. as one'd expect from an ordinary fifo. hence asciilifeform's nitpick.
asciilifeform: diana_coman seems to have an ordinary queue.
asciilifeform: ( 'priority queue', i believe. but from my brief look at diana_coman's posted item, it dun do this )
asciilifeform: can do it, but the resulting data structure called sumthingelse.
asciilifeform: you'd want'em in separate queues, neh? whole point of marking the packets distinguishable by size
asciilifeform: ( ffa is not threaded per se, but is thread-safe, dun allocate anyffing other than on stack, i.e. can be used inside a thread safely )
asciilifeform quite fond of the ada thread model, it's prolly closest one can get to sanity on pc irons
asciilifeform: diana_coman's udp tester was threaded
asciilifeform: mircea_popescu: sorta the philosophy i went with in FG -- redundancy against iron-death error oughta live upstack ( i.e. you plug in >1 ) rather than inside box
asciilifeform: correct, udp quite analogous to, say, radio, you can send but no promises that anyone heard
asciilifeform: if only thing that can kill the socket is killed iron, retrying it won't bring back to life will it.
asciilifeform: and yes death is the correct behaviour.
asciilifeform: ( see if this holds , for various scenarios, yank cord, yank nic )
asciilifeform: diana_coman: my current understanding is that the socket won't ever close, if iron is intact.
asciilifeform: it eats a packet and then tries to send , afaik the os will not report a eggog on send() unless there in fact are no working nics
asciilifeform: mircea_popescu: there ain't a 'connection' in udpology
asciilifeform: diana_coman: have you managed to achieve the socket-closing eggog without directly abusing the lib ? (e.g. by trying to send oversized packet, etc)
asciilifeform: mircea_popescu: threaded worker 'rescuing from nic' into queue, and threaded eaters eating from same, is how asciilifeform baked prototype gossip thing from which udplib taken
asciilifeform: (i.e. added to the kicklist, which rejects packet in O(n log N) where N is number of idjits )
asciilifeform: diana_coman: can send, but then he's a spammer, not client, and gets kicked
asciilifeform: mircea_popescu: in re 'synchronous', it is my understanding that client is not permitted to send a packet unless the n-1'st has been ack'd
asciilifeform: i.e. if client's cord gets pulled, from his pov he will stall, from server's , his character is standing still, and when plugs back in, will live again
asciilifeform: diana_coman: per my current understanding of mircea_popescu's protocol, it is immune to packet loss (i.e. client will retry)
asciilifeform: mircea_popescu: i thought your orig queue was specifically re clog (impedance mismatch) in the unix ip stack
asciilifeform: mircea_popescu: even on hypothetical box with 9000 cpus, still no 'clogs', all you get is that the sender waits on the nic. queue cannot overflow cuz your protocol is synchronous ( server dun send anyffing to client unless asked )
asciilifeform: ( i.e. without the variant packet widths . instantiate one with rsa-width buffer, and 1 w/ serp.width )
asciilifeform: mircea_popescu: if you have 2 sockets, can even use orig variant of udptron.
asciilifeform: it dun make sense, in that light, 'clog' -- all that happens if waiting on nic, is that the sender thread empties its queue slower.
asciilifeform: therefore the call to it won't return until the packet has left the house
asciilifeform: recall also that your udp sender is blocking
asciilifeform: diana_coman: you're cpu bound ( serpent ) so you likely will never hit the bandwidth bound. so the udpgrams will go in ~realtime.
asciilifeform: unix is retarded : limits total # of open sockets. so having >1 not only imposes overhead without achieving anyffing, but will eventually hit ceiling.
asciilifeform: you dun need a socket per client in udpism
asciilifeform: mircea_popescu, diana_coman : you have 1 thread, that monopolizes socket, and fetches from a semaphoric queue ( diana_coman posted such a queue today ). other threads can put whatever on queue, and sender sends.
