10:01 |
asciilifeform |
$ticker btc usd |
10:01 |
busybot |
Current BTC price in USD: $21920.93 |
10:12 |
phf |
http://logs.nosuchlabs.com/log/asciilifeform/2022-07-25#1112217 << reddit knowledge is required to make online points, not actually make products |
10:15 |
phf |
hmm, strangely i didn't get dulapbot packet. possibly will arrive, but it's already been a minute and it's still not here |
10:15 |
dulapbot |
(asciilifeform) 2022-07-25 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-07-25#1112212 << proper package support, for one thing. ( and e.g. ada's 'generic' package thing is useful, see example. ) but see also [https://www.xach.com/naggum/articles/32335327 |
10:16 |
phf |
and now i'm getting a bunch of getdata packets (which i'm at the moment not responding to) |
10:19 |
phf |
i was unfortunately discarding them, and also not providing much detail, and by the time i patched, that's when the last message came in… |
10:19 |
phf |
and *now* i got dulapbot's quote |
10:20 |
phf |
so 10:12 to 10:19 est, that's 7 minutes |
10:22 |
phf |
lol and a few minutes later a dupe arrives of that same dulapbot packet |
10:23 |
phf |
10:22 |
10:24 |
phf |
http://glyf.org/screenshots/pest-packets.png |
10:33 |
phf |
kind of wish for while we're exploring pest there was a "travel path" data in packets. like each hop adds itself to a list of stations |
| |
~ 18 minutes ~ |
10:52 |
asciilifeform |
phf: even if packets were somehow as large as one likes, rather than mtu-sized -- a principle of pestronics is that one doesn't necessarily have any biz knowing anyffin concrete about stations with whom not directly peered |
10:53 |
asciilifeform |
the 1 concession in the current protocol is the bounce counter (which, observe, is entirely promisetronic, a defective or mischevious station could set it to whatever) |
10:53 |
phf |
asciilifeform, that's why i said "while exploring", because we're at least for the next few months if not longer will be observing distributed emergent behaviors of pest stations, and while that's happening it would've been useful to have "debugging information" |
10:53 |
asciilifeform |
right |
10:54 |
asciilifeform |
could approximate this by asking folx for debug log snippets (lemme know if need one) |
10:54 |
asciilifeform |
iirc at one point awt had his 'live' to www |
10:55 |
phf |
well, the interesting question is probably "how did that packet end up here" at different times |
10:55 |
asciilifeform |
phf: as asciilifeform currently understands, 100% of the odd delays in messages currently are from hearsay buffering |
10:56 |
phf |
like for example why did i get a dupe of dulapbot packets. i'm only connected to one station, so that stations filtering ought to not retransmit |
| |
↖ ↖ |
10:56 |
asciilifeform |
indeed |
10:56 |
phf |
asciilifeform, yeah, i figured it's hearsay, but why ~7 minute delay~. that's quite obv longer than hearsay spool |
10:57 |
phf |
and then another 3 minutes pass and i get a dupe |
10:57 |
asciilifeform |
aha, makes no obvious sense per asciilifeform's head model |
10:58 |
* |
asciilifeform in experiments w/ udp, not found any instances of macroscopic propagation delay ( i.e. moar than one'd expect from 'ping time' ) from anywhere to anywhere |
10:58 |
asciilifeform |
so logically this kinda thing has to be a blattaism |
| |
~ 58 minutes ~ |
11:57 |
awt |
I'm seeing this morning a large dump of old dulapbot log quote messages. Looks like somehow the clog was cleared. |
12:03 |
awt |
http://logs.bitdash.io/pest/2022-07-25#1010349 << how often are you getting dupes? Any shared characteristics of the dupes? |
12:03 |
bitbot |
Logged on 2022-07-25 10:56:15 phf[awt]: like for example why did i get a dupe of dulapbot packets. i'm only connected to one station, so that stations filtering ought to not retransmit |
12:07 |
awt |
Perhaps there's a case where a getdata response is received and rebroadcast multiple times before it makes it into the long buffer. |
| |
~ 33 minutes ~ |
12:41 |
* |
asciilifeform neglected to nail this down in spec, but getdata responses ought not to be rebroadcast (and if they are currently being rebroadcast, oughtn't make it past stale filter, unless bug) |
12:43 |
asciilifeform |
a getdata response is only useful to the requester (others, who haven't asked for that msg to be replayed, have no way to distinguish it from enemy replay) |
12:54 |
awt |
blatta marks "expected" messages aka getdata responses and at least tries not to rebroadcast them. |
12:55 |
asciilifeform |
awt: seems that it'd be simple to unambiguously identify'em, neh |
12:55 |
awt |
This message in particular was actually not a getdata response, come to think of it. Was just stuck in the order buffer for a while. |
12:55 |
asciilifeform |
( when requested, added to list; when received, is interned into db; and if recv'd again subseqently, marked dupe and similarly not rebroadcast ) |
12:55 |
asciilifeform |
a |
12:58 |
awt |
no way to know right now if a) message somehow originated twice from dulapbot (unlikely) or b) broadcast from asciilifeform's station to some peer, then reflected back later to ... |
12:59 |
awt |
asciilifeform's station |
12:59 |
awt |
and somehow not yet in the long buffer at that point. |
12:59 |
asciilifeform |
awt: this'd fall under dupe, neh? |
13:00 |
awt |
is dulapbot peered with another station? |
13:00 |
asciilifeform |
awt: peered w/ asciilifeform & billymg's 2 bots currently |
13:02 |
awt |
ah ok so likely your station would have received a dupe via billymg or some other station. |
13:02 |
asciilifeform |
possibly, but dupes in theory oughta vanish rather than keep jumping |
13:03 |
asciilifeform |
the 1 case where not, is when 1) it aint a getdata response + 2) from receiver's pov it aint a dupe (1st time station sees $msg) |
13:03 |
awt |
obviously should vanish, obviously didn't |
13:03 |
asciilifeform |
aha |
13:04 |
awt |
in this case the message was likely in the order buffer of all dulapbot peers for a while before being stored in the long buffer and rebroadcast. |
13:07 |
awt |
because either the self or net chain for that message was broken |
| |
~ 51 minutes ~ |
13:58 |
phf |
well, there's an obv failure point here (ignoring the whys and the hows of the original sin): awt's station rebroadcast same message twice and the delay between messages was >10m |
13:59 |
phf |
http://logs.nosuchlabs.com/log/pest/2022-07-25#1010586 << http://logs.nosuchlabs.com/log/pest/2022-07-25#1010568 that's the entirety of the story (i've seen dupes like that before, but this is first time i took note of it) |
13:59 |
dulapbot |
Logged on 2022-07-25 12:03:21 awt[asciilifeform]: http://logs.bitdash.io/pest/2022-07-25#1010349 << how often are you getting dupes? Any shared characteristics of the dupes? |
13:59 |
bitbot |
Logged on 2022-07-25 10:56:15 phf[awt]: like for example why did i get a dupe of dulapbot packets. i'm only connected to one station, so that stations filtering ought to not retransmit |
13:59 |
dulapbot |
Logged on 2022-07-25 10:24:47 phf[asciilifeform]: http://glyf.org/screenshots/pest-packets.png |
14:04 |
phf |
the weirdness i think is actually with dulapbot, because more often than not, when i send something that requires his response, i get a bunch of getdata messages |
14:05 |
phf |
but i don't have any further insight into things. i'm mostly observing the state of pest net for my own benefit |
14:13 |
asciilifeform |
phf: dulapbot defo behaves peculiarly at times; less so nao than prev. when was only peered via asciilifeform |
14:13 |
asciilifeform |
but even nao periodically 'sits on' msgs for coupla min |
14:14 |
* |
asciilifeform still not instrumented own station to find why still periodically dies on utfism; tho, peculiarly, not seen this effect on dulapbot's |
| |
~ 23 minutes ~ |
14:38 |
phf |
http://glyf.org/screenshots/pest-fonts-and-colors.png |
14:38 |
asciilifeform |
nifty |
| |
~ 55 minutes ~ |
15:34 |
phf |
crashed and lost my packets :( |
| |
~ 3 hours 28 minutes ~ |
19:03 |
whaack |
!e view-height |
19:03 |
trbexplorer |
block_height: 746530 |
19:03 |
trbexplorer |
mins_since_last_block: -2 |
| |
~ 28 minutes ~ |
19:31 |
awt |
I probably won't spend too much time debugging this particular dupe, since it's related to the order buffer, which is slated for removal. |
| |
~ 1 hours 34 minutes ~ |
21:06 |
mod6 |
wb |
| |
~ 1 hours 11 minutes ~ |
22:18 |
asciilifeform |
wb mod6 |
22:24 |
phf |
http://logs.nosuchlabs.com/log/asciilifeform/2022-07-25#1112234 << it only makes sense for their to be a control message that announces data, an equivalent of a torrent record, that allows to initiate a transfer mechanism that's otherwise completely different from pest broadcast operation |
22:24 |
dulapbot |
(asciilifeform) 2022-07-25 asciilifeform: jonsykkel: signpost did not yet post his scheme, but asciilifeform assumed that transfer would begin with e.g. a series of (chained) msgs giving hashes of, say, 1MB slices. then transfer 1 at a time |
22:24 |
asciilifeform |
phf: obv. correct |
22:25 |
asciilifeform |
phf: given that luby convergence aint deterministic, also would make sense to define a 'stop, we're done' |
22:26 |
asciilifeform |
(and an interval after which transmitter stops regardless) |
22:27 |
phf |
i haven't read the paper yet, i somehow missed the part where signpost picked this particular direction up |
22:28 |
* |
asciilifeform considers that there aint any point to attempting lubyism b/w l2+; it oughta be strictly b/w peers, otherwise threatens to get ridiculously bw-hungry and complicated |
22:29 |
asciilifeform |
phf: was originally his suggestion, but nfi where he currently is re subj |
22:29 |
* |
asciilifeform must bbl |
22:29 |
phf |
why not torrent |
22:32 |
phf |
i only briefly looked into relationship between fountain codes and torrent protocol, and not knowing either don't have much to add to conversation yet. my initial guess was that one can probably significantly simplify torrent protocol, when knowing topology of trusted counterparties. but maybe not. |
| |
~ 1 hours 3 minutes ~ |
23:35 |
* |
crtdaydreams recalls |
23:35 |
crtdaydreams |
http://logs.nosuchlabs.com/log/pest/2022-07-25#1010637 << when mentioned earlier, flamed |
| |
↖ ↖ |
23:35 |
dulapbot |
Logged on 2022-07-25 22:29:37 phf[asciilifeform]: why not torrent |
23:35 |
dulapbot |
(asciilifeform) 2022-03-21 crtdaydreams: re DHT/PEST: perhapse we could utilize some form of bittorrent while wrapping i.e. a tracker in pest? |
23:35 |
dulapbot |
(asciilifeform) 2022-03-21 signpost: time to stop trying to satisfy your urges by making noise, and read *deeply* the pest spec, all of loper-os, and come back with questions or not at all. |