<dgrish>
ah, awesome. I'm trying to plug strategies in, specifically by modifying peer_request_queue.go. My question is: what's the intended way to get a peer's ledger? I know there's a function in engine.go, but I'd need an Engine instance for that and I'm not quite sure if that's what i want
<dgrish>
and whyrusleeping thanks, I'll check that out
<whyrusleeping>
dgrish: that PR makes these sorts of things a bit simpler i think
<whyrusleeping>
though the sessions work is totally requester side
<whyrusleeping>
and it sounds like youre looking at responder side, which is good
<whyrusleeping>
dgrish: it doesnt look like the peer_request_queue has any access to a peers wantlist
<whyrusleeping>
this seems like a design flaw
<whyrusleeping>
seems like we should allow for the engine to give access to peers ledgers to the peer_request_queue
<whyrusleeping>
i guess my question would be this: Does the logic you want need to be done in the peer request queue? Or can it be done in the engine, and abstracted to fit the ordering of the peer request queue?
<dgrish>
whyrusleeping: I think the latter case may work, but could you describe a bit more by 'abstracted to fit the ordering of the prq'?
<whyrusleeping>
the peer request queue just takes an ordering function to sort things
<whyrusleeping>
so you could pass that ordering function into the peer request queue constructor from the engine
<whyrusleeping>
right now its hardcoded as 'partnerCompare'
<Bob[m]3>
Why am i getting a whole bunch of Riot messages?
<whyrusleeping>
riot?
obensource has joined #ipfs
MrControll has quit [Quit: Leaving]
ashark_ has joined #ipfs
<lgierth>
matrix client
Bob[m]3 has left #ipfs ["User left"]
<dgrish>
whyrusleeping: gotcha, so then I'd just implement the strategy as an ElemComparator. I'm still missing a piece though (perhaps due to my inexperience with Go) -- the ElemComparator signature would need to accept an Engine as an arg still, wouldn't it?
<whyrusleeping>
No, you could capture it within a closure
<dgrish>
whyrusleeping: ah, that makes perfect sense, thanks! <3 higher order functions
pcre has quit [Remote host closed the connection]
jkilpatr has joined #ipfs
btmsn has quit [Ping timeout: 240 seconds]
wak-work has quit [Ping timeout: 255 seconds]
maxlath has joined #ipfs
erde74 has quit [Ping timeout: 240 seconds]
erde74 has joined #ipfs
ylp has quit [Ping timeout: 252 seconds]
erde74 has quit [Client Quit]
wak-work has joined #ipfs
rendar has quit [Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!]
Encrypt has quit [Quit: Quit]
bwerthmann has quit [Ping timeout: 258 seconds]
ebel has quit [Ping timeout: 258 seconds]
dgrish has quit [Ping timeout: 240 seconds]
dgrish has joined #ipfs
ebel has joined #ipfs
dgrish has quit [Client Quit]
<dgrisham>
whyrusleeping: one more question if you're still around, on the DHT implementation this time
<whyrusleeping>
dgrisham: sure, whatsup?
<dgrisham>
whyrusleeping: you mentioned in the 'connection closing' sprint proposal that IPFS uses tcp by default right now, is that just for convenience? or is there a good argument against udp in this case?
<whyrusleeping>
mostly convenience
<dgrisham>
cool, thought so
bwerthmann has joined #ipfs
wak-work has quit [Ping timeout: 245 seconds]
wak-work has joined #ipfs
<lgierth>
udp needs something on top right now (like udt, utp, quic)
<lgierth>
we're not ready yet to do message/packet based comms
<lgierth>
everything expects an ordered reliable stream
taaeem has joined #ipfs
taaeem has quit [Client Quit]
<dgrisham>
whyrusleeping: back on the bitswap ledger problem -- so to get the ledger, I need the corresponding peer ID. the comparator function gets two `activePartner`s, and the map between peer ID and activePartner is in the prq itself
<dgrisham>
so it seems like I have a weird sort of circular thing going where I can't cleanly get the ID
<whyrusleeping>
does the activePartner not contain the ID?
<whyrusleeping>
if not, go ahead and add it there
<dgrisham>
it doesn't look like it does
<dgrisham>
ah, okay
<dgrisham>
will do
<dgrisham>
and thanks lgierth, that makes sense
Are[m] has joined #ipfs
shazbot4077 has joined #ipfs
abec has joined #ipfs
shazbot4077 has left #ipfs [#ipfs]
azahi has quit [Quit: WeeChat 1.7]
azahi has joined #ipfs
shizy has quit [Ping timeout: 260 seconds]
espadrine has quit [Ping timeout: 255 seconds]
azahi has quit [Ping timeout: 252 seconds]
pcre has joined #ipfs
maxlath has quit [Quit: maxlath]
sirdancealot has quit [Ping timeout: 240 seconds]
Caterpillar has quit [Quit: You were not made to live as brutes, but to follow virtue and knowledge.]
realisation has quit [Ping timeout: 240 seconds]
PorcoRosso70 has joined #ipfs
realisation has joined #ipfs
ashark_ has quit [Ping timeout: 255 seconds]
mahloun has quit [Ping timeout: 252 seconds]
jkilpatr has quit [Ping timeout: 240 seconds]
citizenErased has joined #ipfs
chris613 has joined #ipfs
MrControll has joined #ipfs
jkilpatr has joined #ipfs
cxl000 has quit [Quit: Leaving]
reit has quit [Quit: Leaving]
wrouesnel has quit [Read error: Connection reset by peer]
IridiumScaffold has quit [Read error: Connection reset by peer]