| 00:53 |
awt |
Yeah no real point in testing much more until I can get out a patch that fixes the dup detection problem |
| 00:55 |
awt |
As for PeterL's and billymg's issues, they nothing for ascii to do until they can show some logs of outgoing messages targeted at ascii's station |
| |
~ 1 hours 47 minutes ~ |
| 02:43 |
asciilifeform |
awt: make sense, ty |
| |
~ 10 hours 41 minutes ~ |
| 13:25 |
PeterL |
hey everybody |
| |
↖ |
| 13:30 |
PeterL |
asciilifeform: did you see this one? 2021-11-16 08:17:42.811785 [71.191.220.241:50725] <- 52a65a94ca2003b8 |
| 13:38 |
PeterL |
I think the idea is once we get the kinks ironed out on what the spec should actually contain that people will write a couple versions in languages like c,d,ada, etc |
| 13:39 |
PeterL |
so yes, it is good to write your own |
| 13:42 |
PeterL |
http://btc.info.gf/paste/b670e8@raw << here is some of the debug log, let me know if you think having more of it would help diagnose the connection problem? |
| |
~ 1 hours 21 minutes ~ |
| 15:03 |
asciilifeform |
jonsykkel: plox to repost in #a , seems like the bot lost your logline |
| 15:04 |
asciilifeform |
PeterL: i looked through own debug log, not 1 of your packets made it here, still nfi why |
| 15:04 |
asciilifeform |
seems clear that your station is sending (at least far as dbg log goes) as is mine |
| 15:06 |
asciilifeform |
jonsykkel: is odd, because you're defo within 3 bounces of it |
| 15:06 |
PeterL |
maybe our keys don't match or something? |
| 15:07 |
* |
asciilifeform wonders whether awt's proggy has a < where there oughta be a <= |
| 15:07 |
asciilifeform |
PeterL: if they didn't match, you'd see martians |
| 15:07 |
asciilifeform |
and ditto on my end |
| 15:07 |
asciilifeform |
while neither of us appears to have |
| 15:08 |
asciilifeform |
hm possibly |
| 15:08 |
asciilifeform |
arguably we only have a bucket brigade of this length cuz peering dunwork reliably yet |
| 15:09 |
asciilifeform |
right |
| 15:11 |
* |
asciilifeform must bbl |
| |
~ 1 hours 41 minutes ~ |
| 16:53 |
billymg |
jonsykkel: can you pgpgram me your peering info just so we can see if that solves the logging issue? |
| 17:07 |
billymg |
jonsykkel: ok, added you |
| 17:07 |
jonsykkel |
alrite, test |
| 17:07 |
jonsykkel |
seems to work |
| 17:08 |
billymg |
nice |
| 17:08 |
billymg |
those /alias commands also work in weechat, very helpful |
| |
↖ |
| 17:09 |
billymg |
only slightly different syntax: https://weechat.org/files/doc/stable/weechat_user.en.html#alias_commands |
| 17:09 |
billymg |
the /quote thing was driving me nuts |
| 17:10 |
jonsykkel |
yeah terrible ux |
| 17:13 |
awt |
oh nice to know they work in weechat too |
| 17:14 |
awt |
patch for hash based deduplication coming tonight or tomorrow morning |
| |
~ 28 minutes ~ |
| 17:42 |
PeterL |
http://logs.bitdash.io/pest/2021-11-16#1000692 << saw this one come through twice? |
| 17:42 |
bitbot |
Logged on 2021-11-16 17:08:40 billymg: those /alias commands also work in weechat, very helpful |
| 17:43 |
awt |
same |
| 17:45 |
PeterL |
looks like I got the same message from awt and jonsykkel ? |
| 17:45 |
awt |
dedup was pretty messed up, but it was over-dropping rather than under-dropping, so still don't have an explanation for occasional double messages. |
| 17:47 |
awt |
best guess so far is some how two duplicate messages are being sent to one peer from the source. |
| 17:48 |
awt |
it is difficult to diagnose though because it is intermittent. |
| 17:50 |
awt |
ohhhhhhhh |
| 17:50 |
awt |
possible the message was sent once with one timestamp, and then to another peer with a *different* timestamp |
| 17:51 |
awt |
so next patch should fix if that's the problem |
| 17:53 |
PeterL |
why would the timestamps be different? |
| 17:57 |
awt |
PeterL: because gor broadcast messages blatta grabs the timestamp each time it packs a message for a peer. |
| 17:58 |
PeterL |
hmm, shouldn't timestamp be constant based on when it got the message, and then the same time used for all peers? |
| 17:59 |
awt |
no I'm talking about originating a message not rebroadcasting |
| 17:59 |
awt |
timestamp isn't touched for rebroadcasting |
| 17:59 |
PeterL |
so for broadcasting, it should build the message (timestamp, user, message) and then pack that to each peer |
| 18:00 |
awt |
PeterL: right |
| 18:00 |
PeterL |
right, it should be the same thing when generating - you make a single message and then broadcast it to each peer |
| 18:00 |
awt |
should be yes |
| 18:00 |
awt |
is not |
| 18:12 |
awt |
regarding bounces, the way I tested it when developing was to set up a chain of length three, set MAX_BOUNCES to 0, and verify that the third station never received the message. |
| |
~ 4 hours 21 minutes ~ |
| 22:33 |
awt |
Testing 9988 |
| 22:35 |
jonsykkel |
nice |
| 22:35 |
awt |
So nice blatta sent it twice lol |
| 22:35 |
jonsykkel |
feature |
| 22:43 |
awt |
Interesting fact I discovered while fixing dedup: blatta was writing all rubbish messages to the log table in the db. You may find your db file to be somewhat large. After upgrading you can delete all entries in your log table. Won't break anything. Best to do before starting up blatta though. |