Show Idle (>14 d.) Chans
← 2022-09-06 | 2022-09-08 → ↓
04:03 crtdaydreams hardcopy of sicp came today :D
~ 2 hours 26 minutes ~
06:30 crtdaydreams http://logs.bitdash.io/pest/2022-09-06#1012359 << handle is "crt"daydreams, not "steampunk"daydreams
06:30 bitbot Logged on 2022-09-06 18:16:22 asciilifeform[5]: steam -- simpler, mechanically, and -- with sumthing resembling modern machining -- with turbine, ~similarly efficient to the carburetted 'ice'
06:31 crtdaydreams in all rationale though, defo merit for i.e. boiler-powered workshop using old skool belts and pulleys
06:32 crtdaydreams high torque applications
06:33 crtdaydreams but then again, wai mess with steam machine wen perfectly good D7 in shed that can last over9000 hours
06:34 crtdaydreams be better off using the water for e.g. electrolysis
06:35 crtdaydreams or better yet; Drink it. Fresh water might be scarcity in apocalypse
06:36 crtdaydreams http://logs.bitdash.io/pest/2022-09-06#1012365 << why car? why not balloon?
06:36 bitbot Logged on 2022-09-06 20:53:49 asciilifeform[jonsykkel|crawlerbot|billymg]: ( laff, but occasional crackpot actually proposes 'compressed air car' in earnest. 'folx who can't do arithmetic are doomed to talk nonsense'(tm)(r)(jmc) )
06:38 crtdaydreams perhaps merit to steam with complexity, could make on home lathe & mill if in a pinch
06:40 crtdaydreams will always have shit to burn and water to boil
06:44 crtdaydreams http://logs.bitdash.io/pest/2022-09-06#1012368 << what like cap? not sure what adding a tank would do, there's a finite potential to which you can store superheated pressurized steam efficiently
06:44 bitbot Logged on 2022-09-06 21:05:50 jonsykkel: im joking, but jokes aside, u would have the steam engine + tank to solve the slow to revv problem. why wouldnt that work
06:46 crtdaydreams all it would do is allow you to continue running for a little bit after the boiler has cooled
06:46 jonsykkel u cud use superhot steam to press air into tank then put that into wheels
06:48 crtdaydreams there's a finite linear expansion coefficient and thermal conductivity
06:48 crtdaydreams steam engines can only go so fast
06:49 crtdaydreams s/finite/finite limit to
06:53 jonsykkel maybe it dosnt work, im low steam-iq so i cant say
↖
06:54 crtdaydreams new meaning to "runnin outta steam"
06:54 crtdaydreams tank psi exponentially decayed fug
07:05 * crtdaydreams wonders if we'll ever see airships again
~ 1 hours 26 minutes ~
08:32 jonsykkel in non-steams, ive ben experimenting with nat traversal
08:32 jonsykkel this is my observations
08:33 jonsykkel i got setup that looks like this http://zzz.st/up/EKRUGKwc/20220907_143211.png
08:33 jonsykkel 2 machines behind same nat, 1 behind difrent nat, and 1 not behind any nat
08:33 jonsykkel the natted machines are not able to communicate with each other using the same ext.port as D is using
08:33 jonsykkel if C forwards port, A and B can reach it, but C sees diffrent src ports than what D is seeing
08:33 jonsykkel http://zzz.st/up/eReJlvWl/20220907_143255.png
~ 2 hours 18 minutes ~
10:51 asciilifeform jonsykkel: 2 boxes under 1 nat likely won't link up, addrcast won't help, as you illustrated. fortunately this doesn't often occur in nature
10:53 asciilifeform ( however each of'em ought to still be able to peer with stations ~outside~ that nat )
10:53 jonsykkel ryte but im talking about boxes from different nats trying to link
10:56 jonsykkel seems all the nats im behind cares about where packets come from in adition to port
10:56 asciilifeform jonsykkel: does e.g. 'skype' work from behind your nat? may be worth experiment
10:57 asciilifeform ( not all nats are drillable )
10:57 asciilifeform konsoomer nats typically are
10:58 jonsykkel no idea but does skype even do p2p
10:59 jonsykkel but it does drill, just have to initiate conection from behind nat
11:01 jonsykkel cannot use external port that someone else is using (see fig. 2, nat assigns diffrent ports for difrent hosts outside the nat)
11:01 asciilifeform afaik with 'symmetric' nats of the type apparently victimizing jonsykkel , the only drill that worx is to hammer random ports, from both directions, until match
11:01 jonsykkel weird
11:02 jonsykkel gota read up on that
11:02 jonsykkel why would random ports work
11:02 asciilifeform jonsykkel: be sure to post your findings here
11:02 jonsykkel sure
11:11 jonsykkel oh i see how random hammering owkrs
11:11 jonsykkel will do some experiments
~ 37 minutes ~
11:48 awt http://logs.bitdash.io/pest/2022-09-06#1012221 << any thoughts on this asciilifeform?
11:48 bitbot Logged on 2022-09-06 11:49:29 phf[awt]: awt, so for example if there's a complete pest net of n stations, everyone's online, then 1 station drops out, now the network in aggregate starts transmitting n-1 address cast messages, because everyone is looking for that 1 offline station? 2 station, n-2, etc.
11:49 awt $ticker btc usd
11:49 busybot Current BTC price in USD: $18885.31
~ 18 minutes ~
12:08 asciilifeform awt: indeed you'd want some sorta randomization & backoff there, as suggested by folx in prev thrd
12:09 asciilifeform in fact imho oughta have it across the board, wherever a timeout triggers sumthing 'public'
12:11 asciilifeform awt: of course yer example presupposes that the net is a 'clique' (i.e. erryone-to-erryone peering)
12:11 asciilifeform in actual practice (even on current pestnet) this aint so
12:13 * asciilifeform suspects that even very naive algo, e.g. 'if there is a cold peer in wot -- then erry second 1/60 chance of shooting addrcast to all hot peers' -- would prevent 'chorusing'
12:14 asciilifeform notion in spec was simply that there aint any point in emitting addrcast if yer actually in contact with yer entire wot at given time
12:15 asciilifeform (and otherwise you want periodic beacon so that the missing peer, in the event he still has a working link with 1 or more on the net, can reconnect)
12:17 asciilifeform (ditto ~processing~ addrcast; is rather expensive, so if all yer peers 'hot', no point in doing so)
12:19 phf the icky part is that if your or your counterparty's pest is complete, then you don't have to process anything. but with a single node falling out on either side, you start getting packets or start having to process packets
12:19 phf in practice that means that if one of your nodes falls out, suddenly you have to drink from the firehose of address packets
12:20 asciilifeform phf: correct
12:20 asciilifeform the choice afaik is to 'drink always' or 'drink when missing 1 or moar peer'
12:21 asciilifeform asciilifeform didn't see a point in 'drink always'
12:22 asciilifeform if bandwidth were somehow in infinite supply, could simply carry ~all~ traffic in addrcast-style broadcast msgs. but in practice this'll get outta hand rather quickly.
12:24 asciilifeform (the other , not unimportant, point, is that such 'cheat' would eat away at the p2p topological redundancy of pest. stations oughta directly link up with peers whenever possible, and operator oughta know (via hearsayism) if fails)
12:32 phf i'm more trying to understand this particular mechanism better, because it seems like it feels like it has a potential for a firehose
12:33 phf you have n stations, one drops out, now n-1 stations are sending n-1 packets to each other to find the missing station, indefinitely. which (n-1)*2 decrypt operations on each machine
12:34 asciilifeform phf: the 'firehose' is that addrcasts are broadcasts and thereby may be coming from l2+
12:36 phf it being l2 kind of reduces the load, if you consider n to be a complete pest net, something being l2 implies subgraph size m, where m<n by definition, so inseead of it being n-1 packets, it's m-1
12:37 asciilifeform well note that 'complete n' may vary by station depending on what bounce knob is set to
12:37 asciilifeform but yes
12:40 phf or rather x-missing nodes, n-total stations, m-size of subgraph, ≤x*(m-x) packets, where m=n in the worst case
~ 1 hours 14 minutes ~
13:55 * asciilifeform at various times tried to come up with somehow moar efficient mechanism than addrcast, but utterly failed
13:56 asciilifeform given the prior where 'only peers have any biz knowing yer addr/port', it's afaik the only possible one
13:59 phf asciilifeform, why not make who you're looking for public?
14:00 asciilifeform phf: cuz then you gotta make yer own addr/port public, neh
14:00 asciilifeform the 'who' has to be able to answer.
14:01 phf why would you? e.g. station phf looking for station asciilieform, and here's a crypto payload that only asciilifeform will know
14:02 asciilifeform peers are identified by keys tho (shared strictly b/w the 2 peers)
14:02 phf immediately that'll only solve 2x decode, but then peers can have some kind of coordination thing going
↖
14:02 asciilifeform rather than handles
14:02 asciilifeform (which anyone can set to anyffin)
14:03 phf anyone can also not-retransmit which is functionally equivalent to preventing decode based on target station's nick
14:03 phf lets say it's ascii looking for phf, i know i'm phf, so i decode. attacker changes that to dog, so i don't decode. but then attacker can also simply not send, with same result.
14:03 asciilifeform phf: elaborate plz re 'coordination thing'
14:04 asciilifeform 'looking for phf' in this case means 'here's a phf-encoded addr/port for asciilifeform' tho
14:06 asciilifeform issue with coordination schemes is that not erry peer has biz being able to ask for addr/port of arbitrary peer of $station
14:06 phf yes, but addr/port is payload, coordination can be done at the level "who are we looking for"
14:06 asciilifeform a
14:06 phf if i get 30 packets from asciilifeform that are asking for phf, i can choose to retransmit only a subset of those. that would be one form of coordination
14:07 asciilifeform so notion is to place the handle in addrcast outside the ciphered payload?
14:07 phf i might know where asciilifeform is in the above scenario, because he's in my l1, or i might just wait until he comes up to send him the last packet from a particular set
14:07 phf asciilifeform, yah
14:09 phf but i'm also thinking out loud, because maybe there needs to be more policy around it, if one were to do it
14:09 phf e.g. does l2 need to know who you're looking for, that's possibly a leak
14:11 phf lets come back to this, i want to think about it some more, before i raise it as an explicit RFC :>
14:12 * asciilifeform when orig wrote section, defaulted to 'no one but the target has any biz knowing anyffin', but agree that subj needs thought
↖ ↖ ↖ ↖
14:13 phf the policy might be something like "if you're increasing bounce you should zero out looking-for-station-nick field"
14:13 phf so your l1 knows who you're looking for, but not l2
14:14 phf this will give you enought rope^Wknowledge to do better coordination, letting the subnet be pretty conservative about the address requests
14:15 asciilifeform fwiw addrcast does already include ~originator~ handle outside of ciphered blob
14:15 asciilifeform (but not the target's)
14:15 phf yah
14:17 phf "someone is looking for someone" "phf is lookibng for someone" vs "phf is looking for asciilifeform", that seems like the kind of knowledge that's can be practically applied at different bounce levels, and then scrubbed
14:27 asciilifeform phf: what should l1 actually do with this info tho? intention of addrcast is to diffuse as widely as possible
14:27 asciilifeform so suppose l1 get to avoid expensively decoding the thing if they don't need it. but l2+ is stuck doing so anyway
14:29 asciilifeform (fwiw 'expensive' may be an exaggeration, decoding an addrcast simply costs what decoding 2 ordinary packets costs )
14:32 phf asciilifeform, well, nothing's really "expensive" since we're running this on machine from the future, but so far this is the first mechanism which is a free-for-all
14:33 phf ignore is the other one, but it comes with an explicit policy of "station can decide what to do"
14:40 phf x lookingfor y is the entirety of the fact, from which it's possible to reason. in the simplest case "i know where y is" or "i'm also looking for y". in which case you can reduce the incoming stream to "i'm looking for y" and then you keep a backlog of last packets of everyone who's also looking for y.
14:43 phf so for example in a complete graph of n nodes, where one of the nodes is disconnected, the "everyone's looking for missing node" is n messages every at some die off frequency
14:44 phf where's in current approach it's at least n^2 (but not more, since that's going to get deduped on second bounce), and there's no way to coordinate the die off
14:46 phf re coordinating the die off, if you're already in stable state of looking for y, and there's an eager node that keeps sending "looking for y" messages, you can choose to just go "yeah yeah there's a bunch of people looking for him, settle down"
14:46 asciilifeform phf: fwiw note that per spec, stations aint required to decode addrcasts ('may decode, if spare cycles')
~ 1 hours 2 minutes ~
15:48 asciilifeform phf: 1 aspect not already mentioned is that decoding addrcast doesn't actually cost same as regular packet, because only need to try keys of 'cold' peers
15:48 asciilifeform (for the payload, that is)
15:49 asciilifeform *as two regular packets
15:50 asciilifeform i.e. if you've no cold peers, you stop immediately once see that it's addrcast; if have 1 cold, you try only that key; 2 -- the 2 respective keys; etc
15:51 * asciilifeform not made this explicit in spec, but really oughta
~ 29 minutes ~
16:20 phf i wrote some SIMULATION CODE
16:21 phf because i can't graph theory rightn ow
16:23 phf so far i've discovered that a complete graph pest net of 10 with 1 missing generates 648 packets if everyone node were to send out the request once
16:25 phf a 15 node graph with 3 missing generates 4752 packets
16:27 phf a 20 node graph with 3 missing generates 13872…
16:28 phf that's my “send” http://paste.deedbot.org/?id=10e3
16:30 phf actually that's the simulation code in case anyone wants to check it for mistakes http://paste.deedbot.org/?id=nd1x
~ 30 minutes ~
17:01 asciilifeform phf: possibly also 'can't graph theory' but e.g. 10 where 1 missing oughta result in each of the 9 present stations shooting precisely 8 each (1 getaddr, given as 1 missing peer, going to the 8 remaining -- not counting self)
17:01 asciilifeform similarly for the others ( 15 w/ 3 missing -- each of the present 12 shoots 11 getaddrs in total , etc )
17:01 asciilifeform what am i missing
17:02 phf propagation
17:02 asciilifeform a hm
17:03 phf wait, let me fix some stuff in my code, possibly stupid
17:05 asciilifeform phf: if the graph is fully connected, there'll be no propagation, as the thing'll get deduped
17:05 asciilifeform (or rather, there'll be 1 bounce's worth)
17:05 phf well, that's not what my code is doing :D
17:07 phf ah i think i understand where i'm wrong
17:07 * asciilifeform also aint thinking straight, as the getaddrs are unique per shooter and will in fact propagate to all peers, within bounce limit
17:07 asciilifeform err, addrcasts
17:07 * asciilifeform oughta come back to this thrd when awake
17:08 * asciilifeform bbl
17:10 phf right, i'm not wrong, because in my simulation there's no red layer. so a station generations 1 unique getaddr, that is then sent to all peers
17:20 phf ok, so on 10 1 i get (:TOTAL-SENT 648 :TOTAL-RECEIVED 648 :SAMPLE-SENT 72 :SAMPLE-RECEIVED 72)
17:20 phf current state of simulation code http://paste.deedbot.org/?id=TzYt
↖
17:21 phf the propagation logic is in “meat”, please to rea
17:21 phf d
~ 1 hours 39 minutes ~
19:01 shinohai $ticker btc usd
19:01 busybot Current BTC price in USD: $19338.76
~ 2 hours 6 minutes ~
21:08 jonsykkel ur code relays packets to the guy it recved from
21:08 jonsykkel dosnt make a big difrence in results tho
21:22 phf ah ty
21:24 phf ah poop that breaks the clean interface
21:24 jonsykkel 2bad
21:26 jonsykkel # of pakets sent can be reduced somwat by adding a propagation delay before relaying. only relay to ppl u didnt yet recv a copy from. such mechanism alredy exists in specful pestron in form of hearsay buffer. maybe can be generalized for all pakets that are to be flod routed
21:26 jonsykkel but wil not change the results of this particular test, cuz all nodes are interconected
21:28 phf jonsykkel, the argument from the relevant thread is that there's nothing to hook the concept of "copy" to
21:29 jonsykkel i dont undersand
21:30 jonsykkel hash of message is hook innit (or wat is huk here)
21:31 phf jonsykkel, maybe i'm misunderstanding your proposal also, but each instance of packet in my code correspondes correspondence to what would be a unique hash in prod
21:32 phf but there's also no other data on each packet except origin and hash
21:32 jonsykkel presumably prod=addrcast
21:33 phf i meant "hash in production", and yes each packet is an addrcast
21:33 jonsykkel but it wont be unique since u are relaying them wihtout modification
21:34 phf right
21:34 phf wait, i think i understand what you're saying "only relay to ppl u didnt yet recv a copy from."
21:34 phf that mechanism is already in my code
21:35 phf that's the (unless (cache ...) ...) check
21:36 jonsykkel sec gota think
21:36 phf "such mechanism alredy exists in specful pestron in form of hearsay buffer." right, that's correct, but as far as i understand address message is a broadcast, it's already supposed to share same machinery as a regular broadcast, which is what i'm emulating in simulation
21:40 jonsykkel the cache doesnt do the same thing, if u recv a packet and immediately broadcast it, u might send the packet to a guy who has alredy sent the same packet to u but it hasnt arrived yet
21:41 phf ah fuck
21:41 jonsykkel it doesnt affect ur simulation cuz theres no alive node that is >1 distance from any other alive node
21:44 jonsykkel (and the packets are receved instantly)
21:45 jonsykkel i supose could affect a real net even if 100%interconected, but less likely
21:46 phf i think all this idea communicates is that there might be slightly more packets in air, then the simulation predicts (i'm not sure that's correct, i'm failing to visualize it, because end of day)
21:47 phf the delay just adds jitter though, to probabily of that falling out, but doesn't necessarily predict it
21:47 phf *prevent it
21:48 phf jeez, let me retype that sentance
21:50 phf the delay just adds jitter though to the probabily of the backets being in air despite the cache, but otherwise the delay doesn't prevent that situation from happening
21:50 phf bepis
21:53 phf in related, i sort of assumed that the delay on hearsay was there so that you could get missing packets before you spool them to write only irc log, so that you preserve order, rather than for p2p purposes. i don't know if i'm correct though
21:53 jonsykkel if i understand u corectly, the delay inded dosnt improve things for the first bounce, it probably even makes sense to skip it for first bnc, but it does make a difrence after that
21:55 phf that's my intuition, i'll have to revisit this point though
21:55 jonsykkel i think primary purposes of hearsay for messages is to give the imediate message a chance to arive , or in the case where it never arives, colect the list of peers that u received same mesage from so can be listed in irclog
21:55 phf yeah
21:56 jonsykkel purposes of hearsay bufer delay, that is
21:56 jonsykkel and the same info can be used incidentaly to reduce # of packets in air
~ 18 minutes ~
22:14 phf well, order of arrival matters
22:15 phf or the other option is that my code is buggy. i think i'm going to stop working on it for now
~ 58 minutes ~
23:14 signpost http://paste.deedbot.org/?id=Kc1c << in other news, onlinecodes lisp prototype works now. working through sbcl's optimization warnings atm, refactoring, etc
23:15 signpost planning on turning this prototype into a little command line tool that can send/receive a given file to an IP:PORT
23:24 jonsykkel ur code propagates packets depth first
23:24 jonsykkel but i think ends up with right numbers for math reasons
23:24 jonsykkel at least thats wat proof by mspaint says http://zzz.st/up/PJvbnNoR/20220908_052234.png
↖
23:25 jonsykkel re phfcode, not onlinecode, onlinecode - nice
23:25 signpost ty.bmp
23:26 crtdaydreams http://logs.bitdash.io/pest/2022-09-07#1012570 << mspaint is literally goto wen want to explain something
23:26 bitbot Logged on 2022-09-07 23:24:29 jonsykkel: at least thats wat proof by mspaint says http://zzz.st/up/PJvbnNoR/20220908_052234.png
23:26 crtdaydreams <3
23:27 jonsykkel its a powerful beast to have in ur toolbox
← 2022-09-06 | 2022-09-08 → ↑

Random(pest) | Download hourly DB snapshot | Get Source Code

Theme: Light | Dark | System Default