@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest19353
Irc2PGuest46029
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over
Over1
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cancername
cumlord
dr4wd3_
eyedeekay_bnc
hagen_
khb
mittwerk
not_bob_afk
plap
poriori_
profetikla
rapidash
shiver_
solidx66
u5657_1
uop23ip
w8rabbit
weko_
x74a6
orignal
I mean CA as certificate authority
orignal
zzz, question about streaming
orignal
say you receive message 1 and them message 500
orignal
what do you send in Ack?
orignal
because number of NACKs is limited by 256
zzz
orignal, two answers:
zzz
1) It will never happen, if other-end's max window is 128, which is what Java uses
zzz
2) if it does happen, we will drop #500, and ack 1, and pretend we didn't receive 500, because our receive buffer is 128 messages max, so we don't have "room" for a message 499 ahead
zzz
we treat it as a buffer overflow
zzz
and we send a CHOKE (I think)
orignal
what is CHOKE?
zzz
see the spec
zzz
1) can't guarantee ofc, that's why there is answer 2)
zzz
Optional delay. How many milliseconds the sender of this packet wants the recipient to wait before sending any more data. A value greater than 60000 indicates choking.
zzz
when you get a CHOKE, set your window size to 1
orignal
what is the flag?
zzz
DELAY_REQUESTED
orignal
nice, I don't even handle it
orignal
will drop to 1
zzz
anyway, more details: our rcv buffer max is 1812 * (128 - 2) bytes, we can store more than 128 msgs in there, but we assume all "holes" are max size 1812
zzz
so if we get a msg that would make the buffer including the holes be larger than the max, we drop it and send a choke
orignal
basically I do but don't drop window
zzz
yeah test choke/unchoke (or just what you have now) with local loopback, ^Z the receiver app so the streaming buffer overflows, watch how fast things recover back to normal speed
zzz
if you have bugs, or don't do choke, it might never recover... we used to have that problem
zzz
but it's really rare for rcv buffer to overflow in real world, not worth a ton of work on it as long as you recover *eventually*