punkman: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-02#1060588 << can't you get port from the addr it returns?
dulapbot: Logged on 2021-10-02 15:18:41 thimbronion: Anyone know if it's possible to get the originating remote port from python's recv_from? Trying to figure out how to handle the scenario where a station receives a broadcast from a new address AND new port.
punkman: on another note, might be nice to have different command number for getdata/banner requests and getdata/banner replies.
thimbronion: punkman: you are corrrect - there is a port.
punkman: I'm not handling that scenario either, my AT is IP->Peer map, guess I should convert it to IP:Port->Peer too
punkman: source port in UDP doesn't make much sense though, I wonder if some network softwares fuck it up
thimbronion: punkman: the issue I'm seeing now is the port I get from recvfrom doesn't match the port bound to on the remote host. I suspect it's some local port.
punkman: yeah that's what I meant, but I'm a noob so was guess
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-02#1060590 << billymg i'ma have to check the stockpile and get back to you, will do asap
dulapbot: Logged on 2021-10-02 19:40:57 billymg: asciilifeform: rack service inquiry for whenever you have a chance to read
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-03#1060597 << are you behind a nat ?
dulapbot: Logged on 2021-10-03 12:37:21 thimbronion: punkman: the issue I'm seeing now is the port I get from recvfrom doesn't match the port bound to on the remote host. I suspect it's some local port.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-03#1060593 << elaborate re why. imho worx fine w/out separate #s
dulapbot: Logged on 2021-10-03 02:25:44 punkman: on another note, might be nice to have different command number for getdata/banner requests and getdata/banner replies.
asciilifeform must bbl
mats: https://www.occrp.org/en/the-pandora-papers/massive-leak-exposes-the-hidden-fortunes-of-worlds-elite-and-crooks
thimbronion: asciilifeform: this machine is not behind a nat.
thimbronion: asciilifeform: additionally, for testing purposes these stations are all running on the same machine at different ports.
billymg: asciilifeform: sounds good, no rush
punkman: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-03#1060603 << it's nice to know how to parse Message after only looking at command field. otherwise gotta check content to see if it fits getdata/banner request or reply
dulapbot: Logged on 2021-10-03 12:42:08 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-10-03#1060593 << elaborate re why. imho worx fine w/out separate #s
punkman: I'm thinking it might also be nice to have a "ranged" getdata, I sent getdata request with from_hash (last hash we have before gap) to last_hash (hash we just got that informed us about the gap), and peer blasts all the messages we need to fill gap, without having to send a getdata for each
punkman: would make gap-filling faster, more responsive for operator
punkman: likely not needed, guess we'll see when we test
signpost: punkman: https://pdos.csail.mit.edu/~petar/papers/maymounkov-bigdown.pdf << highly recommended reading
signpost: once you're talking about blasts of more than a single item, questions like "wat do when I lose something" come in, and imho the linked item points to a much better approach than reimplementing tcp shittily
signpost has a WIP item that may bolt nicely to thimbronion's before long, in py
signpost: one lovely consequence of the encoding stream is that, for items multiple peers have, multiple peers can start spraying blocks at you, and you'll reap the benefit of the parallelism without them coordinating with each other on what to send you.
signpost recs as many folks as are interested in this to read the paper, and then the more math-heavy one.
asciilifeform not fond of multipacket answers to a 1-packet question, for the simple reason where 'am i expecting this packet?' gotta be O(1) resolvable
dulapbot: Logged on 2021-10-01 14:12:28 asciilifeform: punkman: sadly asciilifeform not had time to write this section ! and doesn't know when will. intention was 1 hash per msg tho, to make easier calculation of the cpu cost of processing a valid packet.
asciilifeform: signpost: imho lubyism is a++ for pest-style known-peers net, as the need to separately authenticate the frags falls away (i.e. can generally trust that a direct peer is not sending garbage frag)
asciilifeform: for warez application -- perfect
signpost: exactly. I'm saying punkman does not need this for base-layer pest, and pointing to where it has an application.
asciilifeform: (for chat, not really needed, but simple to bolt on as a command code)
asciilifeform: aha