Menu
▾
▴
[ naviserver-Feature Requests-1151137 ] New driver API and Udp module
|
From: SourceForge.net <no...@so...> - 2005-02-25 05:36:31
|
Feature Requests item #1151137, was opened at 2005-02-24 09:01 Message generated for change (Comment added) made by sdeasey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1151137&group_id=130646 Category: C-API Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vlad Seryakov (seryakov) Assigned to: Vlad Seryakov (seryakov) Summary: New driver API and Udp module Initial Comment: Hi guys, Attached is minor driver extensions which do not change existing drivers but add new functionality. There are some cosmetic changes, like moving some fields in the Ns_Sock/Ns_Driver structres so they can be accessed publically and made some private functions public but functionality preserved as before. I included udp driver as an example of new API, and also added ns_sha1 command in the tclmisc.c, it is just one command and it is uses practically everywhere. ------------------------------------------------------------------------- To test udp driver i use new ns_udp command: ossweb:nscp 8> ns_udp send 127.0.0.1 5060 "GET / HTTP/1.0\n\n" HTTP/1.0 200 OK MIME-Version: 1.0 Date: Thu, 24 Feb 2005 05:39:50 GMT Server: NaviServer/4.0.10 Content-Type: text/html; charset=iso-8859-1 Content-Length: 661 Connection: close <HEAD><TITLE>Seryakov's Family Intranet</TITLE></HEAD> ..... ---------------------------------------------------------------------- >Comment By: Stephen Deasey (sdeasey) Date: 2005-02-24 22:36 Message: Logged In: YES user_id=87254 The proxy stuff is too late in the cycle to do much. The request has to be fully parsed by then (for read-ahead). If a proxy function is available, then all filters, the auth phase, registered procs, cleanup procs etc. are bypassed. A lot of that stuff can be very useful for non-HTTP protocols. I don't think handling stuff via a proxy function buys you much. ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-02-24 22:32 Message: Logged In: YES user_id=87254 I don't understand what you're trying to acheive here (well, apart from multi-protocol... :-). The newly exposed Ns_Driver* entry points are quite low level, and so the implementor of the new protocol is left to do a lot of the heavy lifting. For example, the way I read it you have to create your own listen socket and register a callback. Every time a new reaquest comes in a thread is spawned to handle it. From that thread you then submit the parsed request to one of the conn threads. Excessive thread creation and message passing between threads is not going to perform well. And it seems you have to write more code than e.g. the example POP3 driver I posted some time ago. You're also not taking advantage of the other facilities that the server offers. What happens if 1000 connections arrive, do you spawn 1000 threads? You could of course code up some limit checks, but this already exists. What if a client sends you a continuous stream of data, 2GB... etc. By using the driver hooks to provide the new protocol parser, you deny yourself the opportunity to use something like the nsopenssl module. This should work just fine for protocols like SMTP, IMAP, POP3 and probably others. Anyway, I think one of the most carefully coded aspects of the server is it's attention to resource usage. That goes for IO, context switching, memory, etc. It's espescialy nice that most of the time you're not even aware that all this work is being done for you. I'd like new protocol drivers to be able to transparently take advantage of that. Could you take a look at my old POP3 demo driver? It's the attachment nspopd-0.3.tar.bz2 over here: http://sourceforge.net/tracker/index.php?func=detail&aid=973010&group_id=3152&atid=353152 It's not obvious that anything interesting is going on, so it's not much to look at. But actually, conn socket read-ahead is happening eficiently in one thread with async IO, the conn threads are treated as a precious resource (heavy-weight Tcl interps) and are allocated at the last minute, there's an easy API in C and Tcl to implement the actual reading of data from the INBOX (could be from the file system, db etc.). You've got a lot of experience writing servers, what do you think is wrong with this model? What can it not do, or what could it do better? ---------------------------------------------------------------------- Comment By: Vlad Seryakov (seryakov) Date: 2005-02-24 14:29 Message: Logged In: YES user_id=184124 Another thing, once we can submit connections from any place, no need to build any drivers, even in C, i can register new proxy proc and set protocol field in my request, so when submitted, connection will run registered proxy proc. for example: in my smtp driver/module, i create driver, register proxy for smtp: protocol, register callback for the socket. Once connection accepted, in my module i submit that connection to the queue with request-protocl set to smtp:. queue.c will call my proxy handler, which is C function. No need to add anything else. This way even standard aolserver can be extended without touching precious http driver thread. Sorry for sarcasm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1151137&group_id=130646 |
