Very good, so then you folk are definitely the people to talk to. Here's the problem that I'm going to run into (in fact, I already have).
I have some code that acts as a DAV server. It listens to PUT requests, etc, but it actually _forwards_ the PUT request to another server, depending on certain variables. (I woudl be happy to redirect the client, but it's usually a dumb desktop client that pukes when I try to redirect its PUT request). What I incorrectly assumed was that as a RegisteredProc, I would get access to the request, line-by-line if necessary. Now you guys are telling me I don't. The problem is that when a client PUT's a 2 MB file, the server doesn't run until the last byte is PUT. Then it dutifully starts forwarding the file to the next host. Needless to say, this performs very badly. Then when Mac OS X boxes start slamming the hell out of my server with PROPFIND's and they get forwarded in this slow fashion, and performance crawls to a near-halt. What I really want is to have my server-side procedure immediately run, and read a few bytes and add them to the network connection, pipelining the request. I assume people that wanted to use AOLserver to do some kind of proxying would be into the same kind of functionality. But I remember there is some kind of nsproxy doodad somewhere, I'll look into that to see if it has any clues for me. Is there any way I can hook somewhere into the lower levels of stuff to get to the Request in more of a 4K-at-a-time fashion? On Tue, 11 May 2004 15:35:40 -0400, Nathan Folkman <[EMAIL PROTECTED]> wrote: >Exactly. The idea is to keep I/O events isolated to the main driver >thread, which in theory should be more efficient. The goal is to not tie >up connection threads, and have them sitting idle waiting for I/O. > >This model is kind of the best of both worlds - single-threaded event >loop that accepts connections and consumes the request, and >multi-threaded connection threads to do the actual work of the request. > >The ideas are similar to work that's discussed here: > > http://www.eecs.harvard.edu/~mdw/proj/seda/ > >At least this is how I remember things... ;-) > >- Nathan > > >Tom Jackson wrote on 5/11/2004, 3:23 PM: > > > You have to read all the data anyway, but > > now the POSTed data is read in so you don't have a tcl procedure slowly > > reading data and controlling the connection. > > >-- >AOLserver - http://www.aolserver.com/ > >To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the >body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
