examples: add simple-pipe #20
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: decentral1se/iroh-go#20
Reference in New Issue
Block a user
adds a simple example on the way to having something as fully featured as n0's unfortunately named
dumbpipecurrently you can use this to e.g. pipe text files across an iroh connection. where i want to get is something like this but which also works with tcp streams and does so in a very svelte way (not having to reimplement too much of net.Conn/Addr and everything related to that). not sure how far i'll get on that but i want to see :)
as for source code origin declarations: #neverslop
dbb27dfeedto854789084calso kinda progresses #14 in that the SimplePipe type sketches a vague outline of the diff between iroh.SendStream / iroh.RecvStream and go's Reader/Writer interfaces
854789084ctobd83d74e6cbd83d74e6ctod4d0a3229fmarked as wip bc i'd like to figure out how to neatly close on the receiver side. like, what's required from the sender? it could also be a matter of improving my very barebones implementation of the Reader/Writer interfaces so that they function w/ errors as intended
aight i think as of
d2fbde7c3bit does enough now (sends EOF if current data read == 0 && we have previously read data)re my tcp ambitions, this could maybe be a good starting point for launching investigations
(sorry for any & all thinking-out-loud comments that end up in yer email inbox d1!!)
2hrs later edit:
another reference, this time for i2p + tor support. this feels to me like it is going in a more complex direction though. not sure if it is needed or something simpler could do the job
onramp's tor parts might be easier to digest:
after looking at
tor/listen.goi think the gist of this approach is to implement thenet.Listenerinterface. the easy way to do it is to have a struct field that is a literal net.Listener instance -- listen.go's isOnionService.LocalListener-- gotten by callingnet.Listen()to which we can punt most of the implementing ofnet.Listener's interface methodsnext day edit:
here's the newer version of
onrampbut probably a lot more complex to look at for first steps than the earlier versionanother day's edit:
net.Dialgo-i2p/sam3/sam3.god2fbde7c3btodb430e2dff@cblgh loving this, please do continue 🍿🍿🍿
I noticed that if you don't pass
-v -secret ...on the receiver side, it just hangs. Also, if you miss the binary in the.gitignore, it always ends up wanting to be checked in with Git. I've tested this with success locally and remotely. Really Cool ™️Will keep reading along and am very curious about the final API surface 🙏
@decentral1se yo ty for the testing! yeah it hangs but only because the endpoint is randomly generated to be something you don't know about XD latest commit addresses that by always dumping the '-endpoint xxx` line to stderr, which shouldn't cause any issues with redirecting the output to e.g. another file
ty for the .gitignore prod, i'm notoriously bad at including binaries there lol; cerca has a couple of binaries lurking in its git history that are unnecessarily inflating its size because of this tendency hehe
i've got some shit brewin with the tcp brainstorming from above btw but am having some issues with the last mile. rn a bit confused how to prototype the dialing of the incoming tcp connection (currently curl via dumbpipe) so that my iroh+tcp listener process doesn't hang forever waiting for a tcp connection that seemingly is never made
woop woop, my very simple echo serve over iroh is working :)
note to self: don't just hand-wave the Writer/Reader implementation haha :') i think it was getting stuck there a few times and through various small tweaks and absolutely chaotic hardcoding i managed to understand enough of the problem to get this to work. i think a more robust solution would probably look slightly different, especially if there's a 'native dialer' in go for these bits. but dang it works :)!
🥇
Resolved a merge conflict & merged to main:
3b7f953540Pull request closed