IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2026/01/19
&zzz
+R4SAS
+RN_
+T3s|4
+eche|off
+nilbog
+orignal
+postman
+qend-irc2p
+sourceress
Arch
Birdy
Danny
Irc2PGuest30010
Irc2PGuest36077
Irc2PGuest49364
Irc2PGuest51117
Irc2PGuest6564
Irc2PGuest65656
Irc2PGuest67278
Irc2PGuest74235
Irc2PGuest83482
MatrixBot
Onn4l7h
Over
Sleepy
Teeed
Yotsu
__bob_
aargh3
ac9f
acetone_
ahiru
anontor
b3t4f4c3__
cims
dr4wd3_
dr|z3d
duanin2
hababam
hagen_
leopold
makoto
marek
marek22k
n2
noidea
not_bob_afk2
nyaa2pguy
o3d3_
poriori
profetikla
r00tobo
rapidash
solidx66
stormycloud[m]
test7363673
uop23ip
urist_
user_
w8rabbit
zelgomer
orignal zzz, we have a question about i2p.streaming.inactivityTimeout
orignal do you send ping for each stream after 1.5 minutes of incativity?
zzz orignal, there's a separate option i2p.streaming.inactivityAction that says what to do, default which I doubt anybody has ever in history changed, is to send a zero-length data packet
zzz no idea if it works, I've never touched it
orignal oor question is
orignal how do you recognize and close hung streams
orignal say you are dowloding a file from site and that router gone away
orignal looks like you close by some timeout
orignal so what's a param from that timeout?
zzz it will eventually hit a max retransmissions and close
cumlord ah thanks a lot zzz :D
zzz re: RSS?
orignal it's one way communication
orignal you only receive packets
orignal hence you receive nothing then what?
orignal we thhought you send ping and that's how you detect this situation
zzz assuming the inactivity timer stuff is working, I believe it would retransmit the zero-length packet multiple times
orignal please elaborate
orignal I download longer file and send acks only
orignal what do you do?
orignal what is "zero-length packet"?
zzz the same. thought we were talking about behavior on inactivity
orignal you stop receving packets and you stream gets stuck forever
zzz a standard streaming data packet, with a sequence number and a data length of zero
orignal you stop because server is down
orignal how often do you send such packet?
zzz we'd use the standard retransmission timer for it
zzz but I'm not super familiar with this code, I'm just staring at it now
orignal is there a parameter for this?
orignal or just a const?
zzz i2p.streaming.inactivityAction2 (send) (0=noop, 1=disconnect) What to do on an inactivity timeout - do nothing, disconnect, or send a duplicate ack.
zzz i2p.streaming.inactivityTimeout90*1000 Idle time before sending a keepalive
orignal and that's what my original question was )))
orignal so we guess it right
zzz so maybe it doesn't get retransmitted if it's zero data, it's just an ack. Not sure
zzz maybe we just send a dup ack every 90 seconds
orignal *guessed
zzz but it's definitely not a ping
orignal I though "keep-alive" is ping
zzz the spec isn't super clear, but it's an ack, not a ping
orignal why not ping, btw?
zzz ask jrandom ))
orignal I'm asking you what I send ping?
zzz or you could define inactivityAction type 3 and do a ping
orignal also do you send one if one way communication or also if complete idle?
orignal good idea
zzz but anyway, I did misspeak. "zero length data packet" == "dup ack", we don't increment any sequence number
zzz it's only if completely idle. for one-way communication we're sending acks
orignal you are sending acks
orignal but you are not resending acks
zzz so we don't have any disconnect on idle at all by default, it could be a websocket or something, we rely on the user-agent or server to close on idle
zzz right, but then at every 90 seconds we'll send another ack
orignal you are not supposed to resend acks
orignal so if you don't send any retransmittable packet for inactivityTimeout you try to resend ack
zzz says who?
zzz right
orignal I still don't understand
orignal even if you resend ack how do you know if it was delivered or not?
orignal since no seqn
orignal or you send wihtout NoAck?
zzz we don't know if delivered. we don't disconnect on inactivity. we rely on the external client or server to do that
orignal how do you handle in case of browser?
orignal browser is downloading big image
orignal and stopped at half
orignal browser will keep waiting
zzz I think we never set NoAck except for ping packets
zzz browser will eventually give up and close the socket
orignal and it doesn't
orignal onon says it's clean you close such streams after 90 seconds
zzz yeah, maybe not. the problem is websockets or other applications that may just sit there for a long time
orignal well if you send an empty packet you will detect the problem
orignal that sounds right
zzz maybe
orignal the only question is params
orignal how often
orignal and zero length packet must be acked and not sent further
orignal let me check how I handle one
zzz our http persistent connections have a 2 minute timeout
zzz I'm not sure it would work to have a zero length packet with a new sequence number, we might get confused
orignal what does this 2 minutes come from?
zzz that's for HTTP persistent connections that you don't support. It's somewhat arbitrary
zzz so you won't see it
dr|z3d arbitary, but in line with general browser timeouts.
zzz point is just that 90 sec may not be enough, it's application-dependent
orignal what do you do for http proxy?
zzz I don't think we have any timeouts in the proxy after the initial request. It could be a huge GET, or a huge POST. Again, we rely on the browser to give up and close the socket
orignal I check for zero length if (packet->GetLength () > 0)
orignal let's talk to onon
zzz we do have timeouts in our eepGet CLI user-agent
orignal how about httpproxy?
zzz > I don't think we have any timeouts in the proxy after the initial request.
zzz it could be a huge POST and it's two hours before the proxy sees anything back from the server
orignal why? It receives ack
orignal if no ack it will try to resend and give up
zzz this is at the proxy. acks are down in streaming
orignal we are talking about huge GET
orignal as long as you send data it's idle
zzz sure, just saying we have to be careful not to break huge POSTs
zzz but you were asking about the proxy layer ))
orignal I'm asking why steams get closed in Java
orignal and stuck in i2pd
orignal it means something closes them in your code
zzz in general, too many retransmissions, or the server or user-agent gives up. If one direction gets "stuck", either the data doesn't get there, or the ack doesn't get back, either way, we'll eventually hit a retx limit
orignal you stop receiveing new data but you don't know if the server gone away or just end of data
zzz yeah but the browser knows, because either content-length http header, or chunked
orignal browser keeps waiting more data
orignal client see semi-loadaed images
zzz sure, thats what browsers do
orignal they stuck
orignal that's the problem
orignal stuck until you presss f5
zzz that will happen no matter who closes the connection
orignal but behavior is defferent between Java and i2pd
orignal usign the same browser
orignal you definitly do something with it
zzz do you propagate a streaming RESET over to a browser socket.reset() ??? and vice-versa?
orignal in both direction
zzz so what behavior is different?
orignal when you downloand site with images browser stcuk and keep waiting
orignal Java says it's complete after 1.5 minute and stops downloading
orignal even if not complete
orignal i2pd thinks that steam is still alive
zzz java on the client side or server side or both?
orignal on client side
orignal e.g. http proxy
orignal either you close stream or proxy closes it somehow
zzz doesn't sound like either one is right
orignal Java's way sounds fair
orignal if download is stuck close ctream and scoket
zzz maybe fair, but wrong, unless the server side is doing something strange
zzz yeah but we just spent an hour with me saying we don't do that ))
orignal we are trying to understand the difference and want to implement Java behaviour
orignal server side does not it just disappears
zzz yeah but I don't understand because I don't think we do that
orignal well let use investigate more