From: Stephen D. <sd...@gm...> - 2006-07-10 19:02:26
|
NS_FATAL doesn't make any sense. Fatal means unrecoverable error, as in Ns_Fatal(...): and the server exits. Anyway, the following two disagree. Whether they intend "request cannot be parsed" or "driver function not supported", NS_FATAL isn't the way to say it. /* *---------------------------------------------------------------------- * * Ns_DriverSetRequest -- * * Parses request line and sets as current Request struct, should be * in the form: METHOD URL ?PROTO? * * Results: * NS_ERROR in case of empty line * NS_FATAL if request cannot be parsed. * NS_OK if parsed sucessfully * * Side effects: * This is supposed to be called from drivers before the * socket is queued, usually from DriverQueue command. * Primary purpose is to allow non-HTTP drivers to setup * request line so registered callback proc will be called * during connection processing * *---------------------------------------------------------------------- */ /* *---------------------------------------------------------------------- * * SockQueue -- * * Puts socket into connection queue * * Call driver's queue handler for the last checks before actual * connection enqueue. NS_ERROR is valid here because that means * driver does not implement this call, we care about NS_FATAL status * only which means we cannot queue this socket. It is driver's responsibility * to allocate Request structure via Ns_DriverSetRequest call, otherwise * for all non-HTTP or not-parsed sockets this call will fail * * Results: * NS_OK if queued, * NS_ERROR if socket closed because of error * NS_TIMEOUT if queue is full * * Side effects: * None * *---------------------------------------------------------------------- */ |
From: Vlad S. <vl...@cr...> - 2006-07-10 19:05:57
|
NS_FATAL in context of these functions means unrecoverable error, but if name is not very good it can be changed Stephen Deasey wrote: > NS_FATAL doesn't make any sense. Fatal means unrecoverable error, as > in Ns_Fatal(...): and the server exits. > > Anyway, the following two disagree. Whether they intend "request > cannot be parsed" or "driver function not supported", NS_FATAL isn't > the way to say it. > > > /* > *---------------------------------------------------------------------- > * > * Ns_DriverSetRequest -- > * > * Parses request line and sets as current Request struct, should be > * in the form: METHOD URL ?PROTO? > * > * Results: > * NS_ERROR in case of empty line > * NS_FATAL if request cannot be parsed. > * NS_OK if parsed sucessfully > * > * Side effects: > * This is supposed to be called from drivers before the > * socket is queued, usually from DriverQueue command. > * Primary purpose is to allow non-HTTP drivers to setup > * request line so registered callback proc will be called > * during connection processing > * > *---------------------------------------------------------------------- > */ > > /* > *---------------------------------------------------------------------- > * > * SockQueue -- > * > * Puts socket into connection queue > * > * Call driver's queue handler for the last checks before actual > * connection enqueue. NS_ERROR is valid here because that means > * driver does not implement this call, we care about NS_FATAL status > * only which means we cannot queue this socket. It is driver's > responsibility > * to allocate Request structure via Ns_DriverSetRequest call, otherwise > * for all non-HTTP or not-parsed sockets this call will fail > * > * Results: > * NS_OK if queued, > * NS_ERROR if socket closed because of error > * NS_TIMEOUT if queue is full > * > * Side effects: > * None > * > *---------------------------------------------------------------------- > */ > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
From: Stephen D. <sd...@gm...> - 2006-07-10 19:25:23
|
On 7/10/06, Vlad Seryakov <vl...@cr...> wrote: > NS_FATAL in context of these functions means unrecoverable error, but if > name is not very good it can be changed Here's some code checking for NS_FATAL and recovering... if (status == NS_FATAL || sockPtr->reqPtr == NULL || !SetServer(sockPtr)) { SockRelease(sockPtr, SOCK_SERVERREJECT, 0); return NS_ERROR; } It's not just the name though, the distinction seems meaningless, and indeed different parts of the code are confused about what it means. We need to switch back to a socket driver interface with multiple functions, as in the 3.x days. Pushing everything through: typedef int (Ns_DriverProc)(Ns_DriverCmd cmd, Ns_Sock *sock, struct iovec *bufs, int nbufs); just isn't working. Check out the comments for the new NsDriver* wrappers, even the long existing DriverKeep and DriverClose don't make a lot of sense. > Stephen Deasey wrote: > > NS_FATAL doesn't make any sense. Fatal means unrecoverable error, as > > in Ns_Fatal(...): and the server exits. > > > > Anyway, the following two disagree. Whether they intend "request > > cannot be parsed" or "driver function not supported", NS_FATAL isn't > > the way to say it. > > > > > > /* > > *---------------------------------------------------------------------- > > * > > * Ns_DriverSetRequest -- > > * > > * Parses request line and sets as current Request struct, should be > > * in the form: METHOD URL ?PROTO? > > * > > * Results: > > * NS_ERROR in case of empty line > > * NS_FATAL if request cannot be parsed. > > * NS_OK if parsed sucessfully > > * > > * Side effects: > > * This is supposed to be called from drivers before the > > * socket is queued, usually from DriverQueue command. > > * Primary purpose is to allow non-HTTP drivers to setup > > * request line so registered callback proc will be called > > * during connection processing > > * > > *---------------------------------------------------------------------- > > */ > > > > /* > > *---------------------------------------------------------------------- > > * > > * SockQueue -- > > * > > * Puts socket into connection queue > > * > > * Call driver's queue handler for the last checks before actual > > * connection enqueue. NS_ERROR is valid here because that means > > * driver does not implement this call, we care about NS_FATAL status > > * only which means we cannot queue this socket. It is driver's > > responsibility > > * to allocate Request structure via Ns_DriverSetRequest call, otherwise > > * for all non-HTTP or not-parsed sockets this call will fail > > * > > * Results: > > * NS_OK if queued, > > * NS_ERROR if socket closed because of error > > * NS_TIMEOUT if queue is full > > * > > * Side effects: > > * None > > * > > *---------------------------------------------------------------------- > > */ > > > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > naviserver-devel mailing list > > nav...@li... > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > -- > Vlad Seryakov > 571 262-8608 office > vl...@cr... > http://www.crystalballinc.com/vlad/ > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
From: Vlad S. <vl...@cr...> - 2006-07-10 19:29:16
|
i agree, driver interface in the 3.x days was much better and flexible, i was using it and tried to hack 4.x since then. Stephen Deasey wrote: > On 7/10/06, Vlad Seryakov <vl...@cr...> wrote: >> NS_FATAL in context of these functions means unrecoverable error, but if >> name is not very good it can be changed > > Here's some code checking for NS_FATAL and recovering... > > if (status == NS_FATAL || sockPtr->reqPtr == NULL || !SetServer(sockPtr)) { > SockRelease(sockPtr, SOCK_SERVERREJECT, 0); > return NS_ERROR; > } > > It's not just the name though, the distinction seems meaningless, and > indeed different parts of the code are confused about what it means. > > We need to switch back to a socket driver interface with multiple > functions, as in the 3.x days. Pushing everything through: > > typedef int (Ns_DriverProc)(Ns_DriverCmd cmd, Ns_Sock *sock, > struct iovec *bufs, int nbufs); > > just isn't working. Check out the comments for the new NsDriver* > wrappers, even the long existing DriverKeep and DriverClose don't make > a lot of sense. > > > >> Stephen Deasey wrote: >>> NS_FATAL doesn't make any sense. Fatal means unrecoverable error, as >>> in Ns_Fatal(...): and the server exits. >>> >>> Anyway, the following two disagree. Whether they intend "request >>> cannot be parsed" or "driver function not supported", NS_FATAL isn't >>> the way to say it. >>> >>> >>> /* >>> *---------------------------------------------------------------------- >>> * >>> * Ns_DriverSetRequest -- >>> * >>> * Parses request line and sets as current Request struct, should be >>> * in the form: METHOD URL ?PROTO? >>> * >>> * Results: >>> * NS_ERROR in case of empty line >>> * NS_FATAL if request cannot be parsed. >>> * NS_OK if parsed sucessfully >>> * >>> * Side effects: >>> * This is supposed to be called from drivers before the >>> * socket is queued, usually from DriverQueue command. >>> * Primary purpose is to allow non-HTTP drivers to setup >>> * request line so registered callback proc will be called >>> * during connection processing >>> * >>> *---------------------------------------------------------------------- >>> */ >>> >>> /* >>> *---------------------------------------------------------------------- >>> * >>> * SockQueue -- >>> * >>> * Puts socket into connection queue >>> * >>> * Call driver's queue handler for the last checks before actual >>> * connection enqueue. NS_ERROR is valid here because that means >>> * driver does not implement this call, we care about NS_FATAL status >>> * only which means we cannot queue this socket. It is driver's >>> responsibility >>> * to allocate Request structure via Ns_DriverSetRequest call, otherwise >>> * for all non-HTTP or not-parsed sockets this call will fail >>> * >>> * Results: >>> * NS_OK if queued, >>> * NS_ERROR if socket closed because of error >>> * NS_TIMEOUT if queue is full >>> * >>> * Side effects: >>> * None >>> * >>> *---------------------------------------------------------------------- >>> */ >>> >>> >>> ------------------------------------------------------------------------- >>> Using Tomcat but need to do more? Need to support web services, security? >>> Get stuff done quickly with pre-integrated technology to make your job easier >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>> _______________________________________________ >>> naviserver-devel mailing list >>> nav...@li... >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >>> >> -- >> Vlad Seryakov >> 571 262-8608 office >> vl...@cr... >> http://www.crystalballinc.com/vlad/ >> >> >> >> ------------------------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >> > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
From: Stephen D. <sd...@gm...> - 2006-07-10 19:42:02
|
On 7/10/06, Vlad Seryakov <vl...@cr...> wrote: > i agree, driver interface in the 3.x days was much better and flexible, > i was using it and tried to hack 4.x since then. It's not bad if all you want to do is Send/Revc, but it seems we don't. Let's come up with a plan for what functions we need. Accept should go back in, for example. Any ideas how we can cleanly handle UDP? > Stephen Deasey wrote: > > On 7/10/06, Vlad Seryakov <vl...@cr...> wrote: > >> NS_FATAL in context of these functions means unrecoverable error, but if > >> name is not very good it can be changed > > > > Here's some code checking for NS_FATAL and recovering... > > > > if (status == NS_FATAL || sockPtr->reqPtr == NULL || !SetServer(sockPtr)) { > > SockRelease(sockPtr, SOCK_SERVERREJECT, 0); > > return NS_ERROR; > > } > > > > It's not just the name though, the distinction seems meaningless, and > > indeed different parts of the code are confused about what it means. > > > > We need to switch back to a socket driver interface with multiple > > functions, as in the 3.x days. Pushing everything through: > > > > typedef int (Ns_DriverProc)(Ns_DriverCmd cmd, Ns_Sock *sock, > > struct iovec *bufs, int nbufs); > > > > just isn't working. Check out the comments for the new NsDriver* > > wrappers, even the long existing DriverKeep and DriverClose don't make > > a lot of sense. > > > > > > > >> Stephen Deasey wrote: > >>> NS_FATAL doesn't make any sense. Fatal means unrecoverable error, as > >>> in Ns_Fatal(...): and the server exits. > >>> > >>> Anyway, the following two disagree. Whether they intend "request > >>> cannot be parsed" or "driver function not supported", NS_FATAL isn't > >>> the way to say it. > >>> > >>> > >>> /* > >>> *---------------------------------------------------------------------- > >>> * > >>> * Ns_DriverSetRequest -- > >>> * > >>> * Parses request line and sets as current Request struct, should be > >>> * in the form: METHOD URL ?PROTO? > >>> * > >>> * Results: > >>> * NS_ERROR in case of empty line > >>> * NS_FATAL if request cannot be parsed. > >>> * NS_OK if parsed sucessfully > >>> * > >>> * Side effects: > >>> * This is supposed to be called from drivers before the > >>> * socket is queued, usually from DriverQueue command. > >>> * Primary purpose is to allow non-HTTP drivers to setup > >>> * request line so registered callback proc will be called > >>> * during connection processing > >>> * > >>> *---------------------------------------------------------------------- > >>> */ > >>> > >>> /* > >>> *---------------------------------------------------------------------- > >>> * > >>> * SockQueue -- > >>> * > >>> * Puts socket into connection queue > >>> * > >>> * Call driver's queue handler for the last checks before actual > >>> * connection enqueue. NS_ERROR is valid here because that means > >>> * driver does not implement this call, we care about NS_FATAL status > >>> * only which means we cannot queue this socket. It is driver's > >>> responsibility > >>> * to allocate Request structure via Ns_DriverSetRequest call, otherwise > >>> * for all non-HTTP or not-parsed sockets this call will fail > >>> * > >>> * Results: > >>> * NS_OK if queued, > >>> * NS_ERROR if socket closed because of error > >>> * NS_TIMEOUT if queue is full > >>> * > >>> * Side effects: > >>> * None > >>> * > >>> *---------------------------------------------------------------------- > >>> */ > >>> > >>> > >>> ------------------------------------------------------------------------- > >>> Using Tomcat but need to do more? Need to support web services, security? > >>> Get stuff done quickly with pre-integrated technology to make your job easier > >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > >>> _______________________________________________ > >>> naviserver-devel mailing list > >>> nav...@li... > >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > >>> > >> -- > >> Vlad Seryakov > >> 571 262-8608 office > >> vl...@cr... > >> http://www.crystalballinc.com/vlad/ > >> > >> > >> > >> ------------------------------------------------------------------------- > >> Using Tomcat but need to do more? Need to support web services, security? > >> Get stuff done quickly with pre-integrated technology to make your job easier > >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > >> _______________________________________________ > >> naviserver-devel mailing list > >> nav...@li... > >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > >> > > > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > naviserver-devel mailing list > > nav...@li... > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > -- > Vlad Seryakov > 571 262-8608 office > vl...@cr... > http://www.crystalballinc.com/vlad/ > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
From: Vlad S. <vl...@cr...> - 2006-07-10 19:49:44
|
This is from AS 3.3.1 typedef enum { Ns_DrvIdName, Ns_DrvIdStart, Ns_DrvIdAccept, Ns_DrvIdStop, Ns_DrvIdInit, Ns_DrvIdRead, Ns_DrvIdWrite, Ns_DrvIdClose, Ns_DrvIdFree, Ns_DrvIdPeer, Ns_DrvIdLocation, Ns_DrvIdHost, Ns_DrvIdPort, Ns_DrvIdSendFd, Ns_DrvIdSendFile, Ns_DrvIdDetach, Ns_DrvIdConnectionFd, Ns_DrvIdMoveContext, Ns_DrvIdPeerPort } Ns_DrvId; AS 3.x had sock driver basically only and it seems too much work for every driver to reimplement the whole thing, so i would see a driver to be able to reuse as much as possible what already exists in the server and if needed can implement some specific functions. In this case, UDP would implement Recv/Send only, no Accept, the rest continues as usual. Also, i would leave for the driver to decide how run, in own thread or in the main thread. For some rare UDP requests for example which are used for signaling only, having separate thread is too much overhead. Stephen Deasey wrote: > On 7/10/06, Vlad Seryakov <vl...@cr...> wrote: >> i agree, driver interface in the 3.x days was much better and flexible, >> i was using it and tried to hack 4.x since then. > > > It's not bad if all you want to do is Send/Revc, but it seems we > don't. Let's come up with a plan for what functions we need. Accept > should go back in, for example. Any ideas how we can cleanly handle > UDP? > > > >> Stephen Deasey wrote: >>> On 7/10/06, Vlad Seryakov <vl...@cr...> wrote: >>>> NS_FATAL in context of these functions means unrecoverable error, but if >>>> name is not very good it can be changed >>> Here's some code checking for NS_FATAL and recovering... >>> >>> if (status == NS_FATAL || sockPtr->reqPtr == NULL || !SetServer(sockPtr)) { >>> SockRelease(sockPtr, SOCK_SERVERREJECT, 0); >>> return NS_ERROR; >>> } >>> >>> It's not just the name though, the distinction seems meaningless, and >>> indeed different parts of the code are confused about what it means. >>> >>> We need to switch back to a socket driver interface with multiple >>> functions, as in the 3.x days. Pushing everything through: >>> >>> typedef int (Ns_DriverProc)(Ns_DriverCmd cmd, Ns_Sock *sock, >>> struct iovec *bufs, int nbufs); >>> >>> just isn't working. Check out the comments for the new NsDriver* >>> wrappers, even the long existing DriverKeep and DriverClose don't make >>> a lot of sense. >>> >>> >>> >>>> Stephen Deasey wrote: >>>>> NS_FATAL doesn't make any sense. Fatal means unrecoverable error, as >>>>> in Ns_Fatal(...): and the server exits. >>>>> >>>>> Anyway, the following two disagree. Whether they intend "request >>>>> cannot be parsed" or "driver function not supported", NS_FATAL isn't >>>>> the way to say it. >>>>> >>>>> >>>>> /* >>>>> *---------------------------------------------------------------------- >>>>> * >>>>> * Ns_DriverSetRequest -- >>>>> * >>>>> * Parses request line and sets as current Request struct, should be >>>>> * in the form: METHOD URL ?PROTO? >>>>> * >>>>> * Results: >>>>> * NS_ERROR in case of empty line >>>>> * NS_FATAL if request cannot be parsed. >>>>> * NS_OK if parsed sucessfully >>>>> * >>>>> * Side effects: >>>>> * This is supposed to be called from drivers before the >>>>> * socket is queued, usually from DriverQueue command. >>>>> * Primary purpose is to allow non-HTTP drivers to setup >>>>> * request line so registered callback proc will be called >>>>> * during connection processing >>>>> * >>>>> *---------------------------------------------------------------------- >>>>> */ >>>>> >>>>> /* >>>>> *---------------------------------------------------------------------- >>>>> * >>>>> * SockQueue -- >>>>> * >>>>> * Puts socket into connection queue >>>>> * >>>>> * Call driver's queue handler for the last checks before actual >>>>> * connection enqueue. NS_ERROR is valid here because that means >>>>> * driver does not implement this call, we care about NS_FATAL status >>>>> * only which means we cannot queue this socket. It is driver's >>>>> responsibility >>>>> * to allocate Request structure via Ns_DriverSetRequest call, otherwise >>>>> * for all non-HTTP or not-parsed sockets this call will fail >>>>> * >>>>> * Results: >>>>> * NS_OK if queued, >>>>> * NS_ERROR if socket closed because of error >>>>> * NS_TIMEOUT if queue is full >>>>> * >>>>> * Side effects: >>>>> * None >>>>> * >>>>> *---------------------------------------------------------------------- >>>>> */ >>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> Using Tomcat but need to do more? Need to support web services, security? >>>>> Get stuff done quickly with pre-integrated technology to make your job easier >>>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>>>> _______________________________________________ >>>>> naviserver-devel mailing list >>>>> nav...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >>>>> >>>> -- >>>> Vlad Seryakov >>>> 571 262-8608 office >>>> vl...@cr... >>>> http://www.crystalballinc.com/vlad/ >>>> >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> Using Tomcat but need to do more? Need to support web services, security? >>>> Get stuff done quickly with pre-integrated technology to make your job easier >>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>>> _______________________________________________ >>>> naviserver-devel mailing list >>>> nav...@li... >>>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >>>> >>> >>> ------------------------------------------------------------------------- >>> Using Tomcat but need to do more? Need to support web services, security? >>> Get stuff done quickly with pre-integrated technology to make your job easier >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>> _______________________________________________ >>> naviserver-devel mailing list >>> nav...@li... >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >>> >> -- >> Vlad Seryakov >> 571 262-8608 office >> vl...@cr... >> http://www.crystalballinc.com/vlad/ >> >> >> >> ------------------------------------------------------------------------- >> Using Tomcat but need to do more? Need to support web services, security? >> Get stuff done quickly with pre-integrated technology to make your job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >> > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
From: Stephen D. <sd...@gm...> - 2006-07-10 20:16:58
|
On 7/10/06, Vlad Seryakov <vl...@cr...> wrote: > This is from AS 3.3.1 > > typedef enum { > Ns_DrvIdName, > Ns_DrvIdStart, > Ns_DrvIdAccept, > Ns_DrvIdStop, > Ns_DrvIdInit, > Ns_DrvIdRead, > Ns_DrvIdWrite, > Ns_DrvIdClose, > Ns_DrvIdFree, > Ns_DrvIdPeer, > Ns_DrvIdLocation, > Ns_DrvIdHost, > Ns_DrvIdPort, > Ns_DrvIdSendFd, > Ns_DrvIdSendFile, > Ns_DrvIdDetach, > Ns_DrvIdConnectionFd, > Ns_DrvIdMoveContext, > Ns_DrvIdPeerPort > } Ns_DrvId; > > > AS 3.x had sock driver basically only and it seems too much work for > every driver to reimplement the whole thing, so i would see a driver to > be able to reuse as much as possible what already exists in the server > and if needed can implement some specific functions. > In this case, UDP would implement Recv/Send only, no Accept, the rest > continues as usual. > Also, i would leave for the driver to decide how run, in own thread or > in the main thread. For some rare UDP requests for example which are > used for signaling only, having separate thread is too much overhead. > Right, that's too much to implement. The core server should handle threading etc. I guess it's worth clarifying what the "driver" is. It's not multi-protocol support. It's transport. Plain sockets, SSL, peer2peer network, etc. Protocol sits on top. Many protocols use SSL for example, and it should be possible to reuse the SSL socket driver with each of them. |
From: Vlad S. <vl...@cr...> - 2006-07-10 20:30:54
|
right Stephen Deasey wrote: > On 7/10/06, Vlad Seryakov <vl...@cr...> wrote: >> This is from AS 3.3.1 >> >> typedef enum { >> Ns_DrvIdName, >> Ns_DrvIdStart, >> Ns_DrvIdAccept, >> Ns_DrvIdStop, >> Ns_DrvIdInit, >> Ns_DrvIdRead, >> Ns_DrvIdWrite, >> Ns_DrvIdClose, >> Ns_DrvIdFree, >> Ns_DrvIdPeer, >> Ns_DrvIdLocation, >> Ns_DrvIdHost, >> Ns_DrvIdPort, >> Ns_DrvIdSendFd, >> Ns_DrvIdSendFile, >> Ns_DrvIdDetach, >> Ns_DrvIdConnectionFd, >> Ns_DrvIdMoveContext, >> Ns_DrvIdPeerPort >> } Ns_DrvId; >> >> >> AS 3.x had sock driver basically only and it seems too much work for >> every driver to reimplement the whole thing, so i would see a driver to >> be able to reuse as much as possible what already exists in the server >> and if needed can implement some specific functions. >> In this case, UDP would implement Recv/Send only, no Accept, the rest >> continues as usual. >> Also, i would leave for the driver to decide how run, in own thread or >> in the main thread. For some rare UDP requests for example which are >> used for signaling only, having separate thread is too much overhead. >> > > > Right, that's too much to implement. The core server should handle > threading etc. > > I guess it's worth clarifying what the "driver" is. It's not > multi-protocol support. It's transport. Plain sockets, SSL, > peer2peer network, etc. Protocol sits on top. Many protocols use SSL > for example, and it should be possible to reuse the SSL socket driver > with each of them. > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |