@eyedeekay
+R4SAS
+RN
+T3s|4
+Xeha
+acetone
+orignal
+weko
Irc2PGuest67564
Onn4l7h
T3s|4_
anon2
eyedeekay_bnc
goose2
goose2_
j6
not_bob_afk
profetikla
qend-irc2p
shiver_
u5657
unwr
x74a6
zzz
trying to fix a SAM problem, maybe i2pd has it too
zzz
if client does SESSION CREATE, then socket.setSoTimeout(60 sec), then socket.read()
zzz
and times out and closes socket
zzz
I never find out because I'm not doing a read() while I'm building tunnels
zzz
so I don't stop trying to build
zzz
not so easy to fix but I'm trying
zzz
have to start a new thread to do a dummy read()
zzz
and client shouldn't be pipelining commands but if he does it gets more messy
weko
can you answer please?
weko
<+weko> Should I write specific implementation details in proposal, or should I just describe how it works in detail?
zzz
it's up to you
zzz
but I suggest you try to address the security and anonymity issues raised by dr|z3d and me, in whatever you write
zzz
w00t, got the sam fix working
dr|z3d
\o/
zzz
sortof, on the right track anyway
dr|z3d
dunno if it'll help, but i2pchat has an issue with the socket remaining open for a few minutes if the router disappears.
orignal
so, you problem is that you read with tiemout or what?
zzz
gaah java nio, curses mkvore
zzz
no orignal the problem is I'm not reading while I'm building tunnels
orignal
and you can't catch if client closes session?
dr|z3d
I've noticed i2pchat's send file is super slow, dunno if that's related.
orignal
let me check
zzz
no because my loop is { read command; blocking call to create tunnels; write status; read next command }
zzz
I'm testing with netcat and inbound.quantity=7 outbound.quantity=7
zzz
then ^C netcat
zzz
it's fixable but I'm fighting with java about it ))
orignal
very good catch
zzz
I don't know what bitcoin's timeout is
orignal
I don't read socket until I send reply
orignal
will change it
zzz
their timeout is at least 100 seconds because jonatack said he saw one take that long
zzz
hopefully your fix is easier than mine :)
orignal
yes, one line of code
zzz
I'm at almost 100 ((
orignal
void SAMSocket::HandleSessionReadinessCheckTimer (const boost::system::error_code& ecode)
orignal
here we need to check is a socket is still open
orignal
that's all
zzz
yeah, problem I'm having is that socket.isConnected() returns true even after it's closed
zzz
because socket state doesn't change until you try to read from it
orignal
I check it buy timer
orignal
const int SAM_SESSION_READINESS_CHECK_INTERVAL = 20; // in seconds
zzz
happy for you, don't forget to test it :) I thought it would be easy too...
orignal
another good catch
orignal
should change it to 2
orignal
because people compain that i2pd is slow with session creation
orignal
now we see why ))
zzz
ooh yeah, that's 20 seconds minimum?
orignal
yes
orignal
I don't remeber why I set 20 sec
zzz
nice
orignal
will fix
orignal
and add socket
weko
zzz: but I explained why this is not issues; i will try to explain it more
weko
in proposal, sure.
zzz
orignal, jonatack reported a minimum of 45 seconds, so you might have more delays in there... test with inbound.length=0 outbound.length=0
orignal
I check every 20 seconds
orignal
with current network state tunnels build slow
zzz
sure, but it seems like _one_ tunnel build would have been faster than 20 seconds? just a thought
orignal
sometimes for gostcoint it took 2-3 minutes recently
orignal
I was for 1 IB and 1OB
orignal
*wait
zzz
yikes
orignal
yes, in normal state it should we faster
orignal
then 20
orignal
and it's not about inital 20
orignal
it's about 20 second interval