On 02.10.2007, at 23:50, Stephen Deasey wrote: > > - ssl: if you use it (or any other comm module) you'll be surprised > when 'puts' gets written in clear text. >
I won’t > - If you 'puts' rather than ns_write, you may be surprised when > automatic chunking, encoding, compression doesn't work. I won't (be surprised) > > - maxconnections: The server thinks it knows how many clients it's > serving, but by stashing away the socket and returning the conn, it's > under counting. Probably. > > - Accounting for number-of-bytes-written is weak (as it is with the ns > background writer threads). Do not understand? > And now the explanation: the idea of getting the raw connection socket was to *avoid* all that HTTP stuff that server is imposing and to use propriatery protocol after the initial HTTP comm handshake. So, a modified HTTP client would establish the communication using HTTP headers (and all that jazz) and then pass the client (and on the server to the custom protocol code) the RAW socket so both can communicate as they wish, w/o server interfering into the communication. Clear? I already explained that in numerous emails since about 2 years ago. We already utilize that approach in our product where clients use HTTP protocol to obtain the bi-directional comm channel between the peers. After that we pump our own data over that pipe. In this particular example, we are a backup application where clients connect to a public HTTP server and get a private pipe where the actual data to be backed up is transferred from client to the server using our own propriatery wire protocol. So you use all that HTTP infrastructure to establish the "wire" only. Afterwards we are playing our own music. > > We could fix this by creating a custom channel type to wrap the conn > socket rather than use the standard TcpChannel. > > Unfortunately, we don't really have the infrastructure to support > this: > > The current writer thread stuff separates the Sock from the Conn and > writes directly via the NsDriver* calls, so it passes the SSL test, > but doesn't handle the other stuff. For that, you really need a Conn > available. > > So, we might have to move to a model where we can separate a Conn from > it's conn-thread. > > Secondly, none of our Ns_ConnWrite* calls support an asynchronous > mode. > I do not think this is needed. There is already the ns_write that does all that things. If one really wants to handle that from within the Tcl channel, then yes, you need a special Tcl channel driver that would do what ns_write is doing. But then again, you might need all that async stuff (fconfigure $chan -blocking false) which isn't in place. I see that very pragmatically: it is not needed by anybody I know so far. What server already offers is sufficient for most. The [ns_conn chan] satisfies "cornerstone" requirements that some weirdos (like myself) may have. If needed, we may plug that out and solve in some other fashion, I do not care. It seemed just a very easy and convenient place (the ns_conn command) to add this small change. To develop a full-blown Tcl channel driver may require too much work. I currently do not see justification for all that (additional) work. We may be better off concentrating on other, more important areas, that affect everybody. Unless you have some time to burn... I have fairly long experience about writing a Tcl channel driver (hey, this is no rocket science) so I may be of help if you/somebody wants to fill-in this "hole". Cheers, Zoran ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
