awt[asciilifeform]: $ticker btc usd
asciilifeform: !q seen busybot
dulapbot: busybot last seen here on 2021-11-18 09:41:04: PeterL: who is your daddy and what does he do?
asciilifeform: hrm nm mine hasn't the foo[bar] remover
asciilifeform: !q seen busybot[asciilifeform]
dulapbot: busybot[asciilifeform] last seen here on 2022-09-13 11:52:37: Current BTC price in USD: $20835.34
asciilifeform apropos of nuffin, as of today 30yrs of sitting in usa, lol
awt[asciilifeform]: happy intake day
asciilifeform: lolty
PeterL[asciilifeform]: what are we taking in?
awt[asciilifeform]: PeterL: asciilifeform went through USG intake process 30 years ago today, it seems.
jonsykkel[asciilifeform]: asciilifeform: looks good, as far as i can tell u would expect that if both X+Y are live in the net, they will "always" be able to recv addrcasts from each other, and at aprox the same time. but if T_p is comfigured diferently they will start hammering out of sync (also wat happens after H has expired? give up or retrry la
jonsykkel[asciilifeform]: ter)
jonsykkel[asciilifeform]: thing 2: not 100%sure my internal model of nat is corectt but wouldnt the maffs depend hevily on exact nature of nat? at least my understanding of wat the problem looks something like this:
jonsykkel[asciilifeform]: unpredictable (somewat) factors: nat maping table size (no idea, according to some random account, on order of 2^10-2^14 for typical consoomer router, unlikely to be significantly smaller than that 2^10 at least), timeout of the mapings (usually in the range of 30sec to couple minutes max from wat i can figure)
jonsykkel[asciilifeform]: so if we assume "worst case", 30sec timeout, either the table size or the spam interval will be the limiting factor. u prolly dont want to be spamming faster than something like 0.1ms
jonsykkel[asciilifeform]: which means u will have a "moving window" (as rules time out and get replaced with new ones) of at most 30sec/0.1ms = 300k entries (would guess the tables tend to be smaller than this in practice). lets call window size "W" and spam interval "S"
jonsykkel[asciilifeform]: in the case of the maximally annoying nats, each entry in table wil have src+dst ports that both have to match
jonsykkel[asciilifeform]: which means, after this window has been "saturated" (W*S sec has passed), u have W/(64512^2) = between 0.000025% (W=2^10) and 0.0072% (W=300k) chance of succes for every packet that actually arrives
jonsykkel[asciilifeform]: this translates to chance of success (assuming 0%packet loss) within 60sec = 1-((1-W/(64512^2))^(2*(60/S))) = 25.6% (W=2^10) or ~100% (W=300k)
jonsykkel[asciilifeform]: both my nats are definitely of the annoying type, confirmed by experiments (can not send to nat assigned port from the same external host throguh a diffrent udpsocket). the litle data i colected seems to indicate my W might be somewhere in 3k-30k range
jonsykkel[asciilifeform]: also, if retry later after H expired - how to sync?
jonsykkel[asciilifeform]: supose could have flag in the addres casts "i will start hammering T_p sec after sending this packet, if prods fail. plox to do same"
jonsykkel[asciilifeform]: then flag would be set for initial addrcast and then every x min or watever
jonsykkel[asciilifeform]: actualy not sure why i thouhgt "always at arpox same time", thers no guarante of this at all. but i gues the H would be much longer than the adr cast interval
bitbot[asciilifeform]: Logged on 2022-09-20 18:30:50 jonsykkel: asciilifeform: looks good, as far as i can tell u would expect that if both X+Y are live in the net, they will "always" be able to recv addrcasts from each other, and at aprox the same time. but if T_p is comfigured diferently they will start hammering out of sync (also wat happens
asciilifeform: jonsykkel: if operators mostly agree on a default T_c, then hammer will start at roughly same time.
asciilifeform: ( if not, then connection will take multiple hammerings, initiated by >1 addrcast )
asciilifeform: eventually they'll connect.
asciilifeform: ditto T_p etc.
asciilifeform: afaik there are no NATs where it'll start (i.e. lets out udp at all) where hammer won't eventually penetrate.
asciilifeform: old-style (pre-microshit) skype used this algo.
asciilifeform: http://logs.bitdash.io/pest/2022-09-20#1013285 << any idea whether the ephemeral port #s predictable in these ? imho worth a look
bitbot[asciilifeform]: Logged on 2022-09-20 18:31:42 jonsykkel: both my nats are definitely of the annoying type, confirmed by experiments (can not send to nat assigned port from the same external host throguh a diffrent udpsocket). the litle data i colected seems to indicate my W might be somewhere in 3k-30k range
bitbot[asciilifeform]: Logged on 2022-09-19 18:34:53 asciilifeform[4]: suspects that the hammer time can be shortened considerably by preferentially exploring the space around the ephemeral ports seen in successfully-received prods from currently-warm peers -- many NATs issue ephemeral ports sequentially
asciilifeform: http://logs.bitdash.io/pest/2022-09-20#1013287 << not bad idea imho, but possibly not needed if general agreement re intervals
bitbot[asciilifeform]: Logged on 2022-09-20 18:50:57 jonsykkel: supose could have flag in the addres casts "i will start hammering T_p sec after sending this packet, if prods fail. plox to do same"
jonsykkel[asciilifeform]: http://logs.bitdash.io/pest/2022-09-20#1013291 << but common case will prolly be that one guy restarts station rather than working peering going cold while both stations running
bitbot[asciilifeform]: Logged on 2022-09-20 19:50:37 asciilifeform[5]: jonsykkel: if operators mostly agree on a default T_c, then hammer will start at roughly same time.
jonsykkel[asciilifeform]: so, if X restarts station, X and Y are out of sync re coldness of eachother
jonsykkel[asciilifeform]: perhaps can be fixed by simply responding immediately to a received addr cast IF the last one u sent to this peer was long ago
jonsykkel[asciilifeform]: ttp://logs.bitdash.io/pest/2022-09-20#1013297 << one nat was 4g carriers, the other one some router
jonsykkel[asciilifeform]: http://logs.bitdash.io/pest/2022-09-20#1013297 << one nat was 4g carriers, the other one some router
bitbot[asciilifeform]: Logged on 2022-09-20 19:58:38 asciilifeform[6]: http://logs.bitdash.io/pest/2022-09-20#1013285 << any idea whether the ephemeral port #s predictable in these ? imho worth a look
jonsykkel[asciilifeform]: 4g one appeared entirely random every time from the full range
jonsykkel[asciilifeform]: the router seemed to assign ports clustered around the same place, but i dont know whether that was cuz src port was the same, or cuz mappings created around same time
jonsykkel[asciilifeform]: ill try to figure out the logic, but presumably they all work diffrently
jonsykkel[asciilifeform]: http://logs.bitdash.io/pest/2022-09-20#1013304 << or rather, their casts will be out of phase. worst case one guy starts hammering T_a before the other
bitbot[asciilifeform]: Logged on 2022-09-20 20:50:32 jonsykkel: so, if X restarts station, X and Y are out of sync re coldness of eachother
crtdaydreams[asciilifeform]: pestron borked, aborting
jonsykkel[asciilifeform]: ugota update to 96K so it knows wat to do with adres cast
jonsykkel[asciilifeform]: or prod rather
crtdaydreams[asciilifeform]: generally, what do most folks have their address cast interval set to?
crtdaydreams[asciilifeform]: also, unsure if bug or feature, but getting ~minimum~ 5 AC packets from all peers in short interval
crtdaydreams[asciilifeform]: jonsykkel: tried increasing acint but still making 5 AC requests by the looks of it, which chewing up bandwidth, pestron making the requests almost every 10 seconds
jonsykkel[asciilifeform]: crtdaydreams: knob works, u might be seing rebroadcasts of incoming ACs
jonsykkel[asciilifeform]: theres tons of these
crtdaydreams[asciilifeform]: jonsykkel: hm it seems a bit excessive
crtdaydreams[asciilifeform]: whats log output on your end look like? is my pestron blasting AC over9000 times a minute, also 10x'ed my prodint.
jonsykkel[asciilifeform]: crtdaydreams: http://zzz.st/up/E7Riuzjx/
jonsykkel[asciilifeform]: u see outgoing AC hash matches incoming one, aka rebroadcast
jonsykkel[asciilifeform]: exept those last4, which are from my statoin
crtdaydreams[asciilifeform] recalls jonsykkels pentagram diagram of net broadcasts
crtdaydreams[asciilifeform]: exponentially proportional to size of net
jonsykkel[asciilifeform]: u also gota set igint 10000 or smth if wish to minimize bw
crtdaydreams[asciilifeform]: what igint do?
jonsykkel[asciilifeform]: ignore pakets inteval
jonsykkel[asciilifeform]: defalt is once/sec 2 each peer
crtdaydreams[asciilifeform]: this would set to once 10 sec
jonsykkel[asciilifeform]: whihc also ddoses blatas runing on laptop aparently