log☇︎
56300+ entries in 0.033s
asciilifeform: and yes death is the correct behaviour.
asciilifeform: it's like the fg serial socket.
diana_coman: I suppose "ignore" in the sense of let the exception propagate and the program die
mircea_popescu: diana_coman if the socket is in fact closed, your program dies, there's no twowaysabout this.
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.
mircea_popescu: but i mean... if the socket's closed the wrapper returns neh ?
mircea_popescu: well what could the wrapper possibly do other than resend ?
diana_coman: I mean don't keep trying to send on a closed socket sort of thing
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
diana_coman: I don't mean "resend this packet"
asciilifeform: mircea_popescu: there ain't a 'connection' in udpology
diana_coman: but if udp lib closed the socket how would it help?
mircea_popescu: there's two possible situations here. 1. connection has transient problems, resending would help ; 2. connection died, resending will waste more time.
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)
diana_coman: weird because no way to recover even if plugged back in or something
diana_coman: well, udp lib closes the socket in this case
mircea_popescu: diana_coman you proposing it'd be better to resend than ignore ? ☟︎
diana_coman: well yes, it fails to transmit
mircea_popescu: if it isn't, i'd like to know about it, because i quite like the model.
asciilifeform: ( unlike e.g. tcp, where pipe can die )
asciilifeform: it's like fg, the only failure mode is magic smoke release
mircea_popescu: ie the item died ?
diana_coman: to use correct terminology
asciilifeform: i can think of only 1, dead irons
asciilifeform: mircea_popescu phrased it correctly earlier, point is to remove from ip stack the job of queueing
diana_coman: the one thing hanging would be re errors I suppose
mircea_popescu: imo venerable, successful, and mandatory to copy mechanism./
mircea_popescu: ah. "threaded" here means, "task manager spawns processes". think how apache server works.
asciilifeform: ( rather than per-user )
asciilifeform: mircea_popescu: 1 thread for tx, 1 for rx
mircea_popescu: weren;'t you arguing asecond ago the rescuing from nic needn't be threaded ?
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 )
mircea_popescu: diana_coman so then : a) thin wrappers mosrtly to rescue the queue from ip stack into ram ; b) threaded workers later, which may include but will likely not be limited to, specialist decipherers.
asciilifeform: diana_coman: can send, but then he's a spammer, not client, and gets kicked
diana_coman: what is there to stop it
mircea_popescu: asciilifeform im not strictly aware of this. whence the notion ?
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
a111: Logged on 2018-12-13 19:29 mircea_popescu: diana_coman conversely, if they're that thin why do they exist.
mircea_popescu: anyway, i have an answer re http://btcbase.org/log/2018-12-13#1880600 : because this way you take the queue out of the ip stack's 64kb into the 1tb of ram or w/e you use. ☝︎
diana_coman: 3. I think that's to be a dynamic thing basically aka at a higher level server looks and if it needs to, it creates more workers to process those messages accumulating there
diana_coman: 1. expected bottleneck is message processing: encrypting/decrypting sounds most likely but in principle whatever further processing since not even specified yet fully! 2. the everything else is raw udp (aka udp lib) and feeding it/reading from it aka those would be sender/receivers
mircea_popescu: diana_coman to proceed logically : 1. it is factual that the expected bottleneck reasonably is de-serpenting. 2. everything-else then may safely be non-threaded. 3. do we actually want to thread the serpenting part ?
diana_coman: asciilifeform, yes; the idea though was not to lose the packets that made it to the nic though aka because server busy sort of thing
asciilifeform: diana_coman: per my current understanding of mircea_popescu's protocol, it is immune to packet loss (i.e. client will retry)
diana_coman: that's what I've been going round in for most of today!!
mircea_popescu: diana_coman conversely, if they're that thin why do they exist. ☟︎
asciilifeform: mircea_popescu: i thought your orig queue was specifically re clog (impedance mismatch) in the unix ip stack
diana_coman: well, except for the case where 1mn simultaneous clients I suppose but possibly that gets lost before even reaching the nic
diana_coman: well yes, as long as sender/receiver are ultra-thin aka only from/to queue to/from udp lib then no clog expected at socket
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 )
mircea_popescu: diana_coman the expectation that serpenting rather than netsending will be the processing bottleneck is not unfounded, imo.
diana_coman: asciilifeform, I made it generic so I don't have to copy/paste code just for different const
asciilifeform: ( i.e. without the variant packet widths . instantiate one with rsa-width buffer, and 1 w/ serp.width )
diana_coman: doesn't even bother to decrypt or whatnot because anyway it has no info as to keys and all that
mircea_popescu: whole reason to even do it liek this so client can separate its traffic
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.
diana_coman: mircea_popescu, that was my current idea: 2 sockets, one for rsa and one for serpent, with different ports too
mircea_popescu: diana_coman does it then make sense to have a process that has a socket open and handles the serpent queue, and one proces with a different socket open handling the rsa queue (with a view that these :6666 and :6667 ports then get moved to separate machines if need be) ?
asciilifeform: therefore the call to it won't return until the packet has left the house
diana_coman: asciilifeform, I don't follow - 1mn clients can send 1mn datagrams to server, what has serpent to do ?
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.
mircea_popescu: diana_coman the problem's rather, two sockets will possibly clog for fever total msg/sec than one.
diana_coman: asciilifeform, the q is basically: how many messages/sec clogs the socket essentially
asciilifeform: unix is retarded : limits total # of open sockets. so having >1 not only imposes overhead without achieving anyffing, but will eventually hit ceiling.
mircea_popescu: any specifiable meat on that h ?
mircea_popescu: need nothing. does it help to have ?
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.
mircea_popescu: diana_coman thinking of it : the ~server~ very likely wants a lot of sockets ; strictly because talking to multiple clients at same time.
diana_coman: asciilifeform, you do need because 2 different sizes i.e. 2 different udp lib types essentially
mircea_popescu: spawning another one then makes sense.
mircea_popescu: asciilifeform suppose you're on a multi-core cpu, suppose the socket's not filled but the sender is.
asciilifeform: mircea_popescu: with diana_coman's variant of my udp routine, you dun need >1 socket to send
diana_coman: asciilifeform, lol, no, the point there is the sender/receiver layer of a eulora app essentially
mircea_popescu: even go the distance of keeping a task manager to keep spawning them, and giving them sockets ?
mircea_popescu: there's two evident ways to go about this : either have these together in a single chunk that owns a socket ; or else have them independent, in which case what, they share a socket ? they each get a socket ?
mircea_popescu: so, i hear from cto the comms spec's mostly implemented. now, we're at the point where we wanna make a rsa and a serpent sender.
asciilifeform: yea subj is tapped out till i get the box in hands
mircea_popescu: meanwhile, let's hijack this a little for some s.mg discussion.
asciilifeform: mircea_popescu: presently can't think of any reason not to put whole effort, chunk by chunk, on www
mircea_popescu: yes, but n+1 step there is... "well, bolix v2020 comes with 1tb ram. which it uses."
asciilifeform: tricky bit is to turn thing from 'martian artifact' back into bits.
mircea_popescu: we'll see how this goes.
asciilifeform: reconstructed can have whatever one likes, that aint the tricky bit.
mircea_popescu: can has 64GB ram on the cheap now. considering what period pricing was like, 2020 reconstructed bolix'd better have 1TB ram.
asciilifeform: ( i dun recall if the 'xl' actually could be fed 256MB, possibly phf knows )
asciilifeform: re bolix, iirc of the 36bit, 28 were available for addressing, so theoretically can 256MB.
a111: Logged on 2018-12-11 17:34 mircea_popescu: then ~lone man~ of wanna-be rus' yellow man copied item.
mircea_popescu: yes, but the 1st step in the http://btcbase.org/log/2018-12-11#1879649 line will be... "just like bolix but with 1024x the ram" ☝︎
asciilifeform: mircea_popescu: x86 was ~ok when 64k (i.e. prior to introducing 'segments' )
asciilifeform: so will be same thing, only less mass.
mircea_popescu: i have a lingering suspicion we'd like x86 stack a lot better if memory had stayed the size it was WHEN THE DAMNED THING WAS DESIGNED
asciilifeform: i dun think it has any extra addr lines
mircea_popescu: should be fun to see how well "magical tech" works if plugged into LARGE ram.
asciilifeform: while on subj, from the extant photo i already can see that ~90% of the board surface is sram/dram, each of which respectively would fit on a '90s-era 5v 1chip
asciilifeform: ( not banking on it tho, i suspect their heads have fully tissue grafted into arse at this pt )
asciilifeform: and whoknows, perhaps the folx who attempted this in the past will finally pull their heads out of arse and come out into the light
asciilifeform: mircea_popescu: 'physical copy' + place to put logic analyzer sausage, if not obv. earlier (the orig item is pretty cramped)