is nagle disabled? Do we want to do that? What about SO_KEEPALIVE SO_REUSEADDR and possibly even SO_SNDBUF [?] Thanks. -R
On Mon, Jul 28, 2008 at 9:25 AM, Roger Pack < roger.pack at leadmediapartners.com> wrote:> is nagle disabled? Do we want to do that? > What about > SO_KEEPALIVE > SO_REUSEADDR and possibly even SO_SNDBUF [?] >Well, one thing we could do is provide a key in the options hash for socket options when creating TCPSockets and TCPServers, then provide a set of defaults. I could''ve sworn I was setting Socket::SO_REUSEADDR on TCPServers, but apparently I was not. Oddly enough I''ve never encountered problems with it in my TCP servers using Rev... -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rev-talk/attachments/20080728/af10ee72/attachment.html>
Couple of thoughts: One thought for rev would be to have a single generic fail function---like on_resolve_failed calls it by default, same with on_connect_failed, if they''re not yet defined. maybe call it. on_any_failure or something :) In reality it''s not a big deal to have the nicely verbose error messages--it''s just barely confusing for newer users. I would say just use on_close for it, but I''m not sure if that''s what we''d want or not. Anyway just thinking out loud. With the revem for some reason when I add a connection timer outer it ends up closing my server socket. Very very odd--unless starting a server also calls Socket.connect [which it doesn''t that I''m aware of] :) Then there''s this odd case in [at least] OS X still where TCP appears to just give up on a connection half-way through if it''s faced with a period of intense congestion. It never reconnects! Ahh! Any ideas on why that might be happening? Recreatable with EM, too. Man I had assumed TCP would hold my hand with annoyances like this. Apparently I was wrong. I think that it''s just that the ACK''s are getting lost and then the ACK''ed ACK''s are getting lost or something, but why it doesn''t keep retrying is beyond me. adding TCP_NODELAY and SO_KEEPALIVE seem to not fix it. I guess the only answer is to add a connect timer [for lost SYN''s]. And also a read timeout or something when you expect input. Ahh well. =R On Mon, Jul 28, 2008 at 9:25 AM, Roger Pack <roger.pack at leadmediapartners.com> wrote:> is nagle disabled? Do we want to do that? > What about > SO_KEEPALIVE > SO_REUSEADDR and possibly even SO_SNDBUF [?] > > Thanks. > -R >
On Mon, Jul 28, 2008 at 1:20 PM, Roger Pack < roger.pack at leadmediapartners.com> wrote:> Couple of thoughts: > One thought for rev would be to have a single generic fail > function---like on_resolve_failed calls it by default, same with > on_connect_failed, if they''re not yet defined. maybe call it. > on_any_failure or something :) > > In reality it''s not a big deal to have the nicely verbose error > messages--it''s just barely confusing for newer users. > I would say just use on_close for it, but I''m not sure if that''s what > we''d want or not. > Anyway just thinking out loud. >There could be a generic on_failure, but I''d like to keep the rb_funcalls to a minimum.> With the revem for some reason when I add a connection timer outer it > ends up closing my server socket. Very very odd--unless starting a > server also calls Socket.connect [which it doesn''t that I''m aware of]That''s pretty odd. Revactor creates timer objects for every single read / write, and I''ve used it in conjunction with Mongrel and ran ApacheBench against it (Revactor comes up as slower than both Evented Mongrel and Thin, due mainly to the speed problems with detach). Can you pastie a code snippet that causes the problem?> Then there''s this odd case in [at least] OS X still where TCP appears > to just give up on a connection half-way through if it''s faced with a > period of intense congestion. It never reconnects! Ahh! Any ideas on > why that might be happening? Recreatable with EM, too. Man I had > assumed TCP would hold my hand with annoyances like this. Apparently > I was wrong.I''ve never encountered a problem like that, and the main thing I use Rev for is a massively concurrent HTTP fetcher, which I test somewhat regularly on OS X. In fact, it makes connections so fast that it actually overwhelms the NAT implementation on our router before it overwhelms the TCP stack on OS X. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rev-talk/attachments/20080728/900a98c0/attachment.html>