~dr|z3d
@RN
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@zzz
+Hikari
+Minogami
+Xeha
+acetone
+profetikla
+snex
+uop23ip
+weko
An0nm0n
Arch
DeltaOreo
FreefallHeavens
Gid
Irc2PGuest13871
Irc2PGuest2974
Liorar_
Nausicaa_
Onn4l7h
StormyCloudInc
admin
anon
anontor
anu
cheddah
itsjustme_
j6
limak
not_bob_afk
poriori_
qend-irc2p_
u5657
dr|z3d
I'm seeing "403 Connection Reset" in the sidebar update notification, zzz, so looks like it's working.
zzz
super
zzz
thanks for testing
zzz
did you force a reset somehow? or it just happened?
dr|z3d
just happened. I see that from time to time, presumably because the client's taking too long to request headers.
dr|z3d
also had a look at your HTTPResponseOutputStream mods
zzz
yay? nay?
dr|z3d
was messing around with import java.util.concurrent.Executors seeing if there's any value to running gzip in a separate thread.
dr|z3d
looks mostly fine, though I'm tending towards larger buffers.
zzz
dunno why more threads would be better
dr|z3d
one for gzip, one for building out the content?
dr|z3d
possible improvements in delivery time.
zzz
I suggest you stay out of there, it's super messy and used on both browser and server sides
dr|z3d
lol
zzz
not lol at all
zzz
why would creating another thread be faster?
dr|z3d
aside from giving it larger buffers to play with, I think I'm done.
zzz
the thread design is also carefully done to prevent resource attacks
dr|z3d
ok, well it was just a thought, compress on a separate thread, if you don't think there's much value there, then fine.
dr|z3d
there is presumably where brotli could be swapped in if desirable. or a more performant gzip library.
zzz
actually you can't make it a thread.. it's an output stream. whoever is writing to you is the thread, pushing data into you
zzz
think of it as part of a unix pipe
dr|z3d
ok, that makes sense.
dr|z3d
brotli appears to be fairly simple to implement.
zzz
it's the "sink" of the data
dr|z3d
import org.brotli.dec.BrotliInputStream;
dr|z3d
import org.brotli.enc.BrotliOutputStream;
dr|z3d
protected void beginProcessing() throws IOException {
dr|z3d
//out.flush();
dr|z3d
OutputStream po = new BrotliOutputStream(out);
dr|z3d
synchronized(this) {
dr|z3d
out = po;
dr|z3d
}
dr|z3d
}
zzz
ok, do some speed tests vs. gz
zzz
the hard part is dealing with the negotiation
zzz
the more I look at the RFC 2616 encoding stuff the more I realize we're not very standard, it's messy
zzz
but I think we're gonna need x-i2p-gzchunked for keepalive
dr|z3d
how does gzchunked work? you gzip the chunks as they're sent and the client assembles them at the other end?
zzz
you gzip it and then chunk it
zzz
chunk == RFC 2616 chunking
dr|z3d
ok, I think I get the basics.
zzz
but may not be necessary, because technically you know where the end of the gz is.
dr|z3d
speaking of standards, I guess this is the de facto standard for brotli on java: github.com/google/brotli
dr|z3d
so thinking about it some more, the sidebar update checker (notifications)..
dr|z3d
if we're not getting a 404, and the error looks like it may just be transient eg 403 Connection Reset.. might be an idea to reschedule a check earlier than the configured interval.
zzz
deep down in there where you know it's 403, you don't know if you were started manually or automatically
dr|z3d
yeah, I guess it's not likely to happen much, especially if you're telling eepget to do a bunch of retries. seems to have resolved itself here without intervention.
dr|z3d
enough eepget retries and an in-progress update will survive a restart of the update server.
dr|z3d
the blocking check's a bit counterintuitive, it blocks for a certain period and then carries on the check in the background. should probably just be backgrounded.
dr|z3d
and at some point I'll probably get around to decoupling the news and update checks so they don't share the same interval.
zzz
confirmed, transfer-encodings are supposed to be hop-by-hop, and you should dechunk/rechunk at every hop
zzz
we just gzip the chunks which is inside-out
zzz
we have to dechunk, gzip, rechunk
dr|z3d
sounds complex.
zzz
yeah I think it will have to be written up in a proposal
zzz
w00t first successful persistent browser connection since 2005
zzz
INFO [nt Runner 11] .i2ptunnel.I2PTunnelHTTPClient: Keepalive, awaiting request #17
eyedeekay
＼(＾O＾)／
zzz
gitlab really benefits, the XHRs are super chatty
zzz
every 4 seconds
zzz
now over 300 requests on one socket
zzz
I'm so much smarter than I was in 2005 :)
dr|z3d
*pat pat*