335 lines
20 KiB
HTML
335 lines
20 KiB
HTML
<H3>Tuesday, December 30, 2003 22:00:00 CET</H3>
|
|
|
|
<pre>
|
|
<jrandom> 0) hi
|
|
<jrandom> 1) router status
|
|
<jrandom> 2) i2ptunnel
|
|
<jrandom> 3) im
|
|
<jrandom> 4) 0.3 plans
|
|
<jrandom> 5) time synchronization
|
|
<jrandom> 6) ???
|
|
<jrandom> hello mihi, polo
|
|
<polo> hello !
|
|
<mihi> hi jrandom
|
|
<jrandom> 0) hi
|
|
<jrandom> :)
|
|
<rsk> hi
|
|
<i2p> <duck> hi
|
|
<jrandom> 1) router status
|
|
<jrandom> 0.2.3.3 is out, and it seems to be working
|
|
<jrandom> still lots to do, of course
|
|
<jrandom> but this should be the last 0.2 release
|
|
<jrandom> 0.3 is going to add the peer profiling to allow routers to avoid bad routers
|
|
<jrandom> (and 0.3.1 is a revamp of the transports)
|
|
<jrandom> hola Ophite1
|
|
<Ophite1> Heya.
|
|
<rsk> so more overhead for 0.3?
|
|
<jrandom> yes and no
|
|
<jrandom> it will have peer testing, but its going to be more focused
|
|
<rsk> will we see a speed up with path selection?
|
|
<jrandom> yes
|
|
<jrandom> there are those 'liveliness' calculators, and there will be new latency and throughput calculators added
|
|
<jrandom> plus people will be able to tweak their own preferences for particular peers
|
|
<jrandom> e.g. if you know you want to prefer peer X over peer Y, you will be able to give them a weighting bonus of
|
|
some random points
|
|
<mihi> will there be a clean shutdown? *g*
|
|
<jrandom> thats actually a good question mihi
|
|
<jrandom> i2p is getting to the point where it needs an admin interface.
|
|
<jrandom> the longest Job thats holding up its operation is the GenerateStatusConsoleJob
|
|
<jrandom> which can now take up to 4-6 seconds
|
|
<jrandom> (holding everything else up)
|
|
<jrandom> that needs to go async and on demand.
|
|
<jrandom> but i dont want to write a web listener / etc.
|
|
<jrandom> perhaps the reverse - a servlet that starts the router and communicates with it
|
|
<mihi> you don't need a full web server. just when you see GET, return your data.
|
|
<jrandom> right
|
|
<jrandom> you're right, that stuff should be in 0.3 as well.
|
|
<mihi> and when you see something else (like SHUTDOWN), do as you please. of course only from localhost ;)
|
|
<jrandom> aww c'mon
|
|
<mihi> then someone can make a nice admin program
|
|
<jrandom> right
|
|
<mihi> you had some triggers by files, didn't you? are they documented somewhere?
|
|
>>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] requested PING 1072820995 from jrandom
|
|
<jrandom> those were in IDN, not the router itself
|
|
<jrandom> but that might be a good way to go
|
|
<jrandom> its a trivially easy system
|
|
<jrandom> good idea, lets go that way
|
|
<jrandom> (and i can just reuse that code :)
|
|
<i2p> <duck> this magical filestuff starts to look like plan9
|
|
<jrandom> lol
|
|
<mihi> but file triggers require polling
|
|
<jrandom> right mihi, reading a directory every 30s aint that bad
|
|
<mihi> but a ServerSocket#accept is cheaper.
|
|
<mihi> as it won't eat any time. (provided a good OS)
|
|
<mihi> okay, file triggers are better than nothing, sure.
|
|
<jrandom> server socket would allow remote admin
|
|
<jrandom> (when appropriate)
|
|
<jrandom> dunno.
|
|
<jrandom> something to be worked out.
|
|
<jrandom> (or if someone wants to jump on it and code... :)
|
|
<mihi> and server socket could deliver the routerConsole as well.
|
|
<jrandom> right
|
|
<jrandom> ok, 2) i2ptunnel
|
|
<jrandom> :)
|
|
<jrandom> i2ptunnel still rules, and its looking like we want to add a socket based API to control it
|
|
<i2p> <anon> aum's ic2cp2pc plans are off for now?
|
|
<jrandom> yes, ci2cp is dead in the water, replaced with the socket based API to control I2PTunnel
|
|
<jrandom> I think I may be able to throw on that API in the next few days, so he can get churning on the impl
|
|
<mihi> just use a socket, make in.readLine() and feed that line to runCommand() ;)
|
|
<rsk> what does the api give i2p?
|
|
<jrandom> pretty much mihi (except it formats the results and send them back in a standard way)
|
|
<mihi> with an appropriate "logger" to send the commands back.
|
|
<mihi> s/commands/results/
|
|
<jrandom> rsk> it lets application developers build client and server sockets over i2p without dealing with I2CP's
|
|
encryption needs
|
|
<jrandom> right right
|
|
<jrandom> i2ptunnel /does/ have an overhead for situations where there are lots of i2ptunnels
|
|
<jrandom> regardless of the JVM
|
|
<jrandom> i2ptunnel clients create a new destination per client contacted, and the router will perform much worse as
|
|
the number of local destinations grows.
|
|
<rsk> ah
|
|
<jrandom> this is due to the anonymity needs of the network tied to how our encryption works
|
|
<jrandom> for applications who just want to open a tunnel or two to a peer, this new api will RULE
|
|
<jrandom> but for applications that need to talk to lots of other peers, I2CP is the way to go.
|
|
<jrandom> (since that is a single destination, multiplexed by i2cp)
|
|
<jrandom> I suppose its the old TCP vs UDP balance, in a way
|
|
<jrandom> mihi> do you have any thoughts, or some ideas for the future of i2ptunnel?
|
|
<rsk> hows the work on the ip over i2p, or the vpn stuff going?
|
|
<mihi> jrandom: someone write a good streaming api, and then lets i2ptunnel use it.
|
|
<mihi> same for naming server.
|
|
<mihi> perhaps add some sequence numbers if no one does the things above.
|
|
<mihi> which will mean an incompatible change.
|
|
<jrandom> incompatible changes aren't bad, we're early in dev
|
|
<jrandom> (if we could increase the size of of the IDs too to two or four bytes per side as well?)
|
|
<mihi> the streaming api will be an incompatible change nevertheless. and if i2p worked, we don't need sequence
|
|
numbers.
|
|
<jrandom> rsk> on hold, until someone has time to run with it?
|
|
≡ rsk/#i2p thinks incompatible chages are the best kind
|
|
<jrandom> right mihi
|
|
<mihi> ID should be 3 byte atm, so why *increase* to 2 bytes?
|
|
<jrandom> mihi> actually, I'd like to slowly deprecate mode=GUARANTEED and implement that in the streaming api
|
|
≡ mihi/#i2p too
|
|
<jrandom> leaving i2p = IP, not TCP or UDP
|
|
<jrandom> damnit I wish I had another 14 hours in the day.
|
|
<mihi> only 14? ;)
|
|
<jrandom> ;)
|
|
<jrandom> aren't the 3 byte ids derived by both sides of the con? or maybe i'm just confused
|
|
<mihi> each side has an ID of 3 bytes, hovever, only one must be sent at a time.
|
|
<jrandom> perhaps I'll implement the streaming API, rip out GUARANTEED, and add that socket controller next.
|
|
<jrandom> ah ok
|
|
<mihi> see /apps/i2p/i2ptunnel/java/src/protocol.txt
|
|
<jrandom> right right
|
|
<mihi> btw, who misplaced that file *there*?
|
|
≡ jrandom blames eco ;)
|
|
<jrandom> wait, naw, you put 'em there
|
|
<jrandom> didnt you?
|
|
<jrandom> oh wait, no I imported them
|
|
≡ jrandom blames self for being stupid.
|
|
<jrandom> (la la la)
|
|
<jrandom> damn. ok, yeah, working on the streaming API and the socket controller will allow me to mull over the peer
|
|
testing / profiling / selection manifesto
|
|
<jrandom> I'll post that in a few days for comment
|
|
<jrandom> (and it'll get my head out of the router. variety++)
|
|
<jrandom> mihi> anything else on i2ptunnel?
|
|
<mihi> not that i know
|
|
<jrandom> coo'
|
|
<jrandom> (thanks again for taking the time to chime in on this stuff, I know you're busy with fiw and the rest)
|
|
<jrandom> ok, thecrypto isn't here, but he's making progress on the IM app.
|
|
<jrandom> (thats agenda item 3)
|
|
<jrandom> 4) 0.3 plans
|
|
<jrandom> 0.3.0 ~= peer profiling stuff, and now it'll also include the streaming api and that socket controller for
|
|
i2ptunnel
|
|
<jrandom> but, if you couldn't guess, its not going to be released on jan 1
|
|
<jrandom> jan 15 is an outside possibility. we'll see how things go.
|
|
<jrandom> 0.3.1 isn't a full month of work, so it may not need to get bumped.
|
|
<jrandom> other than that, the roadmap is still pretty much on track and representative of where we're moving
|
|
<jrandom> 5) time synchronization
|
|
<jrandom> a new faq is posted at http://wiki.invisiblenet.net/iip-wiki?I2PTiming
|
|
<jrandom> mihi, you had a suggestion about the fourth option there (building our own in-i2p timing)?
|
|
<jrandom> hi brawl
|
|
<mihi> yep.
|
|
∙φ∙ brawl is now known as eco_
|
|
<eco_> hi guys
|
|
<jrandom> oh heya eco
|
|
<mihi> you should connect 3 random nodes and remember the diff between the avg time and local time.
|
|
<jrandom> we just discussed the streaming API / tunnel api
|
|
<mihi> and then hack up your own getTimeMillis that corrects that.
|
|
<Ophite1> mihi: No, you shouldn't.
|
|
<jrandom> mihi> so if an attacker creates 1000 nodes with the wrong time, everyone gets screwed
|
|
<jrandom> (since avg would skew randomly in between)
|
|
<mihi> if an attacker creates 1000 nodes, everyone gets screwed anyway...?
|
|
<rsk> wouldnt that be self corecting?
|
|
<Ophite1> mihi: OK, 3.
|
|
<jrandom> no, we should be able to handle that mihi.
|
|
<mihi> okay, then only use avg, if standard deviation is lower than 1sec or so.
|
|
<rsk> if everyone has the same time your ok, even if that time is wrong, right?
|
|
<jrandom> rsk> if all 1000 nodes were in sync, but what if they're all random
|
|
<mihi> only use times that are close enough together. if not, take 3 new nodes.
|
|
<jrandom> mihi> right, we could implement NTP (which basically does what you say, using a series of candidate averages
|
|
to iteratively close in on the correct time
|
|
<mihi> but we need not care of everything (like ping latencies), as ntp does.
|
|
<Ophite1> if we did not, mihi, time would slowly creep backwards.
|
|
≡ mihi/#i2p thinks that is better than let users set their time individually.
|
|
<jrandom> so anyone who randomly picks 3 of those skewed nodes gets sent onto their own private network?
|
|
<jrandom> what about that third option -
|
|
<jrandom> i2p has a component that checks with a real NTP server via NTP or SNTP
|
|
<mihi> if you have only skewed notes in your netDB, you are on that private net as well...
|
|
<jrandom> rather than reimplementing the wheel
|
|
<Ophite1> while I partially like that one...
|
|
<Ophite1> NTP isn't signed, it's subject to an MITM attack.
|
|
<Ophite1> or dns cache poisoning for, say, time.nist.gov
|
|
<jrandom> right Ophite1, though with 200,000+ SNTP or NTP hosts, thats a large set to attack.
|
|
<jrandom> we would definitely not sync of time.nist.gov.
|
|
<Ophite1> connections from i2p to the NSA's time server might raise a few eyebrows, ne? :)
|
|
<jrandom> and if an attacker goes after time.nist.gov, everyone everywhere is affected
|
|
<jrandom> heh
|
|
<mihi> then we combine both. ask a "real" ntp server and your neighbor. if both say the same, it's okay.
|
|
<jrandom> so even /more/ code ;)
|
|
<jrandom> but yeah, thats reasonable.
|
|
<Ophite1> That's interesting. And if they don't?
|
|
<Ophite1> pick another ntp server?
|
|
<jrandom> refuse the peer.
|
|
<mihi> try other ntp server and another peer.
|
|
<mihi> until you have a match. then refuse all prev peers.
|
|
≡ mihi/#i2p types slower than jrandom :(
|
|
<Ophite1> match within a certain threshold, say 1sec?
|
|
<jrandom> 1s would be good.
|
|
<jrandom> accepting peers up to 30s or so (to deal with lag)
|
|
<Ophite1> is 1 sec okay on HEAVILY LADEN connections?
|
|
<jrandom> 1s for syncing, 30s for comm.
|
|
<Ophite1> I've seen latency on DSL get to 5 seconds when doing evil things to it.
|
|
<jrandom> with tcp or udp?
|
|
<Ophite1> but then, in that case, that host might not be the one you want to sync time to anyway ;)
|
|
<jrandom> right
|
|
<Ophite1> udp.
|
|
<jrandom> hmm 'k
|
|
<Ophite1> you'd have thought it'd get dropped :)
|
|
<i2p> <duck> I think that the problem is more letting the user know that there is a problem
|
|
<jrandom> duck> that is true.
|
|
<i2p> <duck> only after walking through big logs they see that their clock is off (if they find it)
|
|
<Ophite1> Maybe. Sort of.
|
|
<i2p> <duck> or that the port is already bound
|
|
<jrandom> an admin interface would be nice.
|
|
<i2p> <duck> the world is better with everybody using NTP connected to their local stantrum (sp) 2 server
|
|
CTCP Cloaking is now [On]
|
|
<jrandom> perhaps we'll have a 0.4 release with a bunch of cleanups and end user things, prior to going 1.0?
|
|
<jrandom> right (stratum)
|
|
<i2p> <duck> only windows clients are not likely to have that
|
|
<i2p> <duck> but they are also not likely to be stable
|
|
<jrandom> windows has NTP
|
|
<i2p> <duck> so who cares
|
|
<Ophite1> duck: Windows XP and Windows Server 2003 include NTP.
|
|
<jrandom> a shitload easier than with unix too
|
|
<Ophite1> sync'ed by default to time.windows.com iirc.
|
|
<jrandom> with drop down options for others
|
|
<Ophite1> It's an essential part of Windows Product Activation.
|
|
<Ophite1> can't expire if you don't know the time :)
|
|
<jrandom> heh
|
|
<mihi> no option at my university... all clocks are 1 hour to 5 hours off. but i might not be allowed to run i2p there
|
|
anyway...
|
|
<Ophite1> mihi: i2p should try especially hard to work in such a situation...
|
|
<jrandom> mihi> awesome! you can help test out the hidden operation :)
|
|
<jrandom> as an aside, I'm going to be doing some traveling this summer
|
|
<jrandom> i'll likely be offline, without my laptop.
|
|
<i2p> <duck> sidethought: ntp.duck.i2p :)
|
|
<Ophite1> Look at it like this: Brianna Kazaa downloads cool new anonymous filesharing client which her best friend
|
|
told her was really cool and lets you chat to people secretly and stuff. Do we want to tell her that she
|
|
needs to set her clock within 30 seconds (how will she get some?)? Or do we want it to just work?
|
|
<jrandom> but I'm going to make sure I can still be on I2P with just public terminals.
|
|
CTCP Cloaking is now [Off]
|
|
<jrandom> no brainer Ophite1. just work (with docs for geeks)
|
|
<jrandom> duck> bootstrap ;)
|
|
<jrandom> and i2p will /not/ require root.
|
|
<Ophite1> That's my point.
|
|
<Ophite1> jrandom: would you run a router on a box you didn't have root to?
|
|
<jrandom> so yeah, a mix between option 3 and 4
|
|
<Ophite1> option 3.5 sounds cool to me ;)
|
|
<jrandom> Ophite1> i'd run a hundred of them :)
|
|
<mihi> option 3.1415926...
|
|
<jrandom> (and move on to the next lab, run a hundred more)
|
|
<Ophite1> Ooh. Pie. Tasty.;)
|
|
<Ophite1> jrandom: I said you didn't have root on. Amateur. :)
|
|
<jrandom> lol
|
|
<jrandom> so thats basically where we're looking.
|
|
<jrandom> until the time stuff is implemented, everyone should use option 1 or 2.
|
|
<jrandom> for option 2, if someone could write up some docs, I'd appreciate it
|
|
<Ophite1> that's acceptable for now as we are Not Yet Ready for Brianna Kazaa et al ;)
|
|
<mihi> jftr: i won't test "hidden operation". my univ account has already been disabled once and i don't want it
|
|
another time blocked...
|
|
<Ophite1> mihi: You are the best test we could possibly have.
|
|
<jrandom> Ophite1 > not for test.
|
|
<jrandom> 'k mihi, we'll find a way, and once its ready you'll be able to use it.
|
|
<Ophite1> OK, maybe not test. Some unis get shirty enough to chuck you out rather than just block you.
|
|
<Ophite1> I know someone at the most anti-filesharing pro-RIAA university in the USA. He runs a 2gbit dumpsite.
|
|
<jrandom> lol nice
|
|
<Ophite1> I appreciate that very, very few people are this ballsy.
|
|
<jrandom> ok, thats it for time synchronization.
|
|
<jrandom> eco_> hi. any bt stuff you want to talk about? {or save till next week}
|
|
<Ophite1> but bear in mind the majority of the internet is in future probably going to become university/corporate.
|
|
i2p might be banned. i2p might WELL be considered abuse by major ISPs. i2p will have to work anyway.
|
|
<Ophite1> I have a few interesting ideas along that angle I will present at a future date.
|
|
<jrandom> word
|
|
<Ophite1> (transport)
|
|
<rsk> i2p is considered abuse by major ISPs, read your contract
|
|
<Ophite1> rsk: running a distributed proxy cache?
|
|
<rsk> running any 'server'
|
|
<Ophite1> rsk: Not unless it relays to SMTP or WWW.
|
|
<jrandom> running services of any time
|
|
<jrandom> right
|
|
<Ophite1> rsk: Hehe, I have a solution to that ;)
|
|
<eco_> jrandom: can give a brief update
|
|
<jrandom> floor is yours :)
|
|
<eco_> i'm porting the java-based bittorrent client snark (www.klomp.org/snark) to get aquainted with i2p
|
|
<eco_> first port runs on top of i2ptunnel, directly calling the java classes
|
|
<eco_> current state: does work with 2 peers, things get messed up with > 2, tunnels aren't cleaned up, so restarting
|
|
is painful
|
|
<eco_> eta: this weekend
|
|
≡ eco_/#i2p realises that this might be considered > 2003
|
|
<jrandom> w00t!
|
|
≡ jrandom hacks time.nist.gov
|
|
<eco_> a "real" port would probably cut the overhead of the tunnels, but that's a next step
|
|
<jrandom> cool
|
|
≡ eco_/#i2p gives floor back to mc jrandom
|
|
<jrandom> 'k, I think that was it
|
|
<jrandom> 6) ???
|
|
<jrandom> anyone have anything else?
|
|
≡ eco_/#i2p would like to express his thanks for the job well done by jrandom cs up to now
|
|
<eco_> and that sleep has some use for home sapiens, though jrandom seems to prove this false
|
|
<jrandom> ;)
|
|
<jrandom> what are y'all's thoughts on meeting here as opposed to iip, until i2p is reliable enough?
|
|
<jrandom> personally, I'm tired of meetings being cut to shreds every week.
|
|
<i2p> <anon> lilo sucks!
|
|
<eco_> we might be shutting people out by going here
|
|
<jrandom> we are, I know.
|
|
<jrandom> if we can get an iip<-->here bridge
|
|
<i2p> <duck> IIP is shutting ppl out each day
|
|
<jrandom> that'd be good.
|
|
<jrandom> right.
|
|
<jrandom> iip is, unfortunately, unusable for a reliable development community.
|
|
<i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html
|
|
<i2p> <duck> that is the code where eyeKon etc is based on
|
|
<jrandom> and while I like to go off coding on my own, y'all come up with really good ideas and do good stuff that is
|
|
essential
|
|
≡ rsk/#i2p is writing a windows update script
|
|
<i2p> <duck> theoretically it could connect to 3 servers and mirror each of them
|
|
<jrandom> word duck, perhaps I'll try to get one running on i2p.dnsalias.net
|
|
<jrandom> ping flood from hell ;)
|
|
<eco_> irc at duck.i2p was pretty good today, beat iip
|
|
<jrandom> agreed
|
|
<jrandom> dropped me a few times though.
|
|
<jrandom> perhaps it'll be more reliable next week
|
|
<eco_> it's in your hands :-)
|
|
<jrandom> reliability probably won't improve until 0.3, which is ~2 weeks out
|
|
<jrandom> (1 week to do the tunnel/streaming stuff, 1 week for peer profiling / testing)
|
|
<jrandom> then there'll be whatever bugs that introduces :)
|
|
<jrandom> though I should say I was really excited to stream audio from aum last night
|
|
<jrandom> and ardvark was able to stream for 42 minutes without buffering!
|
|
<jrandom> so perhaps we can be reliable enough
|
|
<jrandom> (my local router is phttp only, which is probably a slight cause)
|
|
<jrandom> ok, anyone have anything else?
|
|
<i2p> <duck> cant thing of anything
|
|
≡ eco_/#i2p can't either
|
|
≡ jrandom winds up...
|
|
≡ jrandom *baf*s the meeting closed
|
|
|
|
</pre> |