+ 2004-08-16 Dossy Shiobara [EMAIL PROTECTED]
+
+ * nsd/driver.c (1.34): Win32 platform doesn't support mmap().
+ Maybe should define HAVE_MMAP instead in the future.
Maybe we should use:
CreateFileMapping
MapViewOfFile
UnmapViewOfFile
and emulate mmap() instead? I
Hi!
I would like to start a discussion which will eventually lead
to one of the two proposals listed below (one from Vlad Seryakov
and the other from Stephen Deasey) included in the core-server
distribution.
Both proposals look promising and both allow us to add support
for arbitrary protocols
Very interesting. After only reading your nutshell descriptions, to me
what would seem like a nice way of handling this is lightweight plumbing
in C and the bulk in Tcl. Example:
Create a socket driver that, on connection to it's IP/port, gets an
interpreter thread and in it runs the procedure
On Tue, Aug 17, 2004 at 10:32:56AM +0200, Zoran Vasiljevic wrote:
Vlad's patch implements entirely new socket-level driver and sticks
the whole add-in functionality in the driver itself, effectively
Stephen's patch integrates into the AS by adding new API call
[...]
from a connection socket.
On Tuesday 17 August 2004 11:59, Andrew Piskorski wrote:
On Tue, Aug 17, 2004 at 10:32:56AM +0200, Zoran Vasiljevic wrote:
Vlad's patch implements entirely new socket-level driver and sticks
the whole add-in functionality in the driver itself, effectively
Stephen's patch integrates into
On Tuesday 17 August 2004 11:28, Bas Scheffers wrote:
Very interesting. After only reading your nutshell descriptions, to me
what would seem like a nice way of handling this is lightweight plumbing
in C and the bulk in Tcl. Example:
Create a socket driver that, on connection to it's IP/port,
On 2004.08.17, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
So, all of you interested in extending AS to handle non-http
protocols, please go, have a look and give some feedback.
Just the other night, I had the need to implement a non-HTTP server in
AOLserver in order to implement the TiVo beacon
On Tuesday 17 August 2004 13:46, Dossy Shiobara wrote:
Just the other night, I had the need to implement a non-HTTP server in
AOLserver in order to implement the TiVo beacon connection for the
Home Media Option (MHO) feature of the Series2 TiVo. I thought about
both Vlad's and Stephen's
Wow, thanks! You mentioned that there might be a performance hit with
this option--any guess as to how significant that would be?
IRA
Sorry -- no data. I'm guessing that for all but the busiest and/or
memory
consuming the difference wouldn't be noticed. The other thing
On 2004.08.17, Zoran Vasiljevic [EMAIL PROTECTED] wrote:
The thing is: you may couple tclhttpd with some db-libraries
plus Tcl threading extension and get more-less a fully functional,
performant multi-threaded webserver in no-time.
Yet, we still use AS. The question is: why?
Unless that was
On Tue, 2004-08-17 at 03:59, Andrew Piskorski wrote:
On Tue, Aug 17, 2004 at 10:32:56AM +0200, Zoran Vasiljevic wrote:
Vlad's patch implements entirely new socket-level driver and sticks
the whole add-in functionality in the driver itself, effectively
Stephen's patch integrates into the
On Tue, 2004-08-17 at 05:46, Dossy Shiobara wrote:
So far, this has been working really well for me. No modification to
the core involved, and it's implemented in very few LOC overall. Using
the same pattern, I could easily implement an SMTP, IMAP, etc., server
in pure Tcl. I'm not sure
On Tue, 2004-08-17 at 03:28, Bas Scheffers wrote:
Very interesting. After only reading your nutshell descriptions, to me
what would seem like a nice way of handling this is lightweight plumbing
in C and the bulk in Tcl.
This is the essence of my proposed solution. You are required to write
a
On Tuesday 17 August 2004 14:55, Dossy Shiobara wrote:
Certainly. My own input into the discussion shouldn't preclude others
from participating. However, I tend to believe that my opinion also
counts and deserves to be voiced along with everyone else's for
consideration.
Absolutely.
On Wed, Aug 11, 2004 at 09:26:20AM +0200, Zoran Vasiljevic wrote:
When you launch the AOLserver in foreground, run couple of requests
and then ctrl-c it, purify should report all memory that has been
allocated and not freed. The list may be long, since AS does not
make a very clean shutdown
On Tuesday 17 August 2004 15:37, Andrew Piskorski wrote:
On Wed, Aug 11, 2004 at 09:26:20AM +0200, Zoran Vasiljevic wrote:
When you launch the AOLserver in foreground, run couple of requests
and then ctrl-c it, purify should report all memory that has been
allocated and not freed. The list
On Tue, 2004-08-17 at 06:55, Dossy Shiobara wrote:
I could very well be wrong. If someone is interested in finding an
off-the-shelf, or implementing from scratch, a load generator for one of
these non-HTTP protocols (say, SMTP) ... I'd like to have a bake-off.
Implemented in pure Tcl, and
This is what i 've done with my first version of SMTP driver, i wrote it
in pure Tcl. Performance was terrible, the site was serving
thousands of incoming SMTP connections and it was very slow. Second
version was doing pretty same stuff but in C, i registered TCP callback
and create new thread for
Off topic, but somewhat related... ;-) I know Tcl can't be used in all
cases, and that sometimes you have to write C code to accomplish what's
needed, but hopefully everyone can see the advantages of keeping as much
code as possible up at the Tcl level.
I think we should continue to really look at
On 2004.08.17, Stephen Deasey [EMAIL PROTECTED] wrote:
The performance difference would certainly be noticeable.
As long as we're clear that we're BOTH speculating here, then I'm okay
with your statement. If you're asserting this to be true, where's the
proof?
In your example code a new
On Tuesday 17 August 2004 16:01, Nathan Folkman wrote:
Off topic, but somewhat related... ;-) I know Tcl can't be used in all
cases, and that sometimes you have to write C code to accomplish what's
needed, but hopefully everyone can see the advantages of keeping as much
code as possible up at
Rather than implement thread pools in pure Tcl, why not just expose AS'
thread pool implementation at the Tcl level? That way, in the end,
there's only one code base to test and update.
Keep in mind, I'm not saying its better, I'm really just curious.
Rob Seeger
Dossy Shiobara wrote on
On Tuesday 17 August 2004 10:32, Zoran Vasiljevic wrote:
I would like to start a discussion which will eventually lead
to one of the two proposals listed below (one from Vlad Seryakov
and the other from Stephen Deasey) included in the core-server
distribution.
I anticipated that this one may
On Tuesday 17 August 2004 16:25, Robert Seeger wrote:
There is one other reason... to do things with the Tcl or AOLServer C
level that can't be done in pure Tcl (that are specific to Tcl/AS, not
the OS). There are a variety of things that can be done in C that just
cannot be done in Tcl, as
It is not thread pools by itself but more reusing existing thread pools.
If you have AOLServer thread pools and Tcl thread pools and if you have
100 connections always connected to the server and using SMTP and HTTP
(this is my case) both AOLServer pools and Tcl pools would
compete for the same
On Tuesday 17 August 2004 10:17 am, Zoran Vasiljevic wrote:
b. NO, I do not need AS doing anything else than http
and am perfectly happy with status-quo now. Just
forget the whole thing.
This is my vote. Let's keep things simple and let's keep things working. Why
is this even on
On Tuesday 17 August 2004 20:12, Don Baccus wrote:
On Tuesday 17 August 2004 10:17 am, Zoran Vasiljevic wrote:
b. NO, I do not need AS doing anything else than http
and am perfectly happy with status-quo now. Just
forget the whole thing.
This is my vote. Let's keep things
This one brings the question: why not go and abstract other
#ifdef's arround the code? Perhaps adding a compat or win/unix or
such directory with platform-specific stuff a'la Tcl? I'm not sure
how bit that effort is, but is worth examining since it will ease
the server maintenance greatly. AOL is
[EMAIL PROTECTED] wrote:
This one brings the question: why not go and abstract other
#ifdef's arround the code? Perhaps adding a compat or win/unix or
such directory with platform-specific stuff a'la Tcl? I'm not sure
how bit that effort is, but is worth examining since it will ease
the server
On Tuesday 17 August 2004 10:59 am, Zoran Vasiljevic wrote:
Why is this on the table? Because there are people looking for
this kind of functionality and because two of them invested
great deal of time to get it working for themselves. And, they
posted a RFE and are willing to share their
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
This one brings the question: why not go and abstract other
#ifdef's arround the code? Perhaps adding a compat or win/unix or
such directory with platform-specific stuff a'la Tcl? I'm not sure
how bit that effort is, but is worth examining since it
[EMAIL PROTECTED] wrote:
On Tuesday 17 August 2004 10:59 am, Zoran Vasiljevic wrote:
Why is this on the table? Because there are people looking for
this kind of functionality and because two of them invested
great deal of time to get it working for themselves. And, they
posted a RFE and are
On 2004.08.17, Don Baccus [EMAIL PROTECTED] wrote:
And, yes, I realize OpenSSL isn't part of the AOLserver core proper,
but it's importance is such that it might as well be.
I've been trying, with little luck, to reproduce the problems people
have been seeing with nsopenssl.
Janine has offered
On Tuesday 17 August 2004 20:55, Don Baccus wrote:
Fine. But there's no reason to push forward on this immediately. Resources
are finite, triage and prioritization are important
Of course. There is no need to push this. It is, if at all, going
to be the part of the development branch for 4.1
On Tuesday 17 August 2004 20:17, you wrote:
To maximize portability, AOLserver could probably use the Tcl API even more
than it does now, and in a few cases modules aren't taking advantage of the
portability abstractions we already have, for example, in the latest
nsopenssl sources, struct
I definitely vote for a). I think AS has a very
powerful framework that can be used outside of http.
--- Zoran Vasiljevic [EMAIL PROTECTED] wrote:
On Tuesday 17 August 2004 10:32, Zoran Vasiljevic
wrote:
Hi!
I would like to start a discussion which will
eventually lead
to one of the
On Tue, Aug 17, 2004 at 08:55:26AM -0400, Dossy Shiobara wrote:
I see two classes of people using AOLserver for implementing non-HTTP
servers:
1) Low to medium performance requirements, short development timeline,
need for rapid development, programmers with low to average technical
On August 6, there were some changes at AOL that folks may want to be
aware of.
The first is that Mark Page has left AOL. We all wish him the best in
his new gig. If we're lucky, maybe he'll still keep an eye on the
project and poke around once in a while.
The second change is that Elizabeth
On Tue, Aug 17, 2004 at 07:17:52PM +0200, Zoran Vasiljevic wrote:
a. YES, I like AS to be more powerful multiprotocol
server instead of being a powerful http-server only.
And, I like proposal X better than Y because of Z.
I'd like to hear more discussion first, but so far my vote
Patrick,
Thanks for replying to my mail. The problem I was facing was totally
alien to what I thought would be. It so happened that the server code
was converting Http POST requests to GET and thus all my form data
submitted was lost in the process. I came to know by luckily analyzing
server's
On 2004.08.17, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
IMO, this is all BS. I don't mean any disrespect, but if I wanted
a mail server, I'd install a mail server. I don't go on the sendmail
list screaming for it to support http :)
Let me rephrase what I think Donald was trying to say,
On Tuesday 17 August 2004 11:51 am, Dossy Shiobara wrote:
Janine has offered to help, but cannot provide access to her production
environments where the problem is occurring.
Sloan's going to try to reproduce it in the next week or two, at which time I
plan to dig around in gdb ...
--
Don
On 2004.08.17, Andrew Piskorski [EMAIL PROTECTED] wrote:
Therefore, fairly arguing that, No, we should NOT apply EITHER of
these two multi-protocol patches, BECAUSE... requires that the
BECAUSE part suggest real, actual NEGATIVES to these patches, and at
least the possibility that these
From my point of view, focusing on protocols is not necessarily the
only reason to want thread pools. I'm not all that familiar with AS 4
yet, so maybe I'm being dense here... keep that in mind. :)
The reason thread pools would be interesting to me personally is to be
able to control quality of
On Tue, Aug 17, 2004 at 08:55:26AM -0400, Dossy Shiobara wrote:
For example, arguments along the lines of:
- The patches will make the code more complicated, uglier, bug prone,
or harder to maintain.
Three of the four points above are a given.
1. The code will be more complicated.
2. More
On Tuesday 17 August 2004 11:51 am, Dossy Shiobara wrote:
Janine has offered to help, but cannot provide access to her production
environments where the problem is occurring.
Actually I can, but what I can't do is put AOLserver 4 + nsopenssl beta
21 back into production. Right now I am running
Time and energy have been already spent by implementing/testing those
patches, why are we circling around that somebody need
to spend efforts to make AOLServer worse HTTP server and better non-HTTP
server. Nobody needs to do anything, AOLServer
still remains http server, those patches do not even
Ah, but therein lies what I think Dossy takes issue with. No, they don't
change the http processing. But... if the http processing changes, the
patches can break. I think the general idea Dossy is getting at is to
think about a way to implement the functionality such that it is not
tied in to the
Of course they are kludges, AOLServer and 4.x versions in particular,
designed to be HTTP only.
Current AOLServer driver model considers HTTP protocol only and is being
optimized to support
HTTP or HTTP-like protocols only. I doubt AOL will ever change the whole
driver model again to
un-HTTP it,
Just because things have gone wrong in the past, does not mean we should
not work to avoid it in the future.
Rob Seeger
Vlad Seryakov wrote on 8/17/2004, 4:59 PM:
As for breaking if driver changes, haven't it happened with versions
3.1, 3.5, 4.0, 4.1.
With every version we have bunch of
Time and energy have been already spent by implementing/testing those
patches
Arguments of this sort apply to EVERY patch and have nothing to do with
whether or not it's a good idea to apply them to the code.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply
The reason thread pools would be interesting to me personally is to be
able to control quality of service better. For example, I may want a
pool of 5 threads to handle search engine spidering requests, and a
pool of 5 threads to handle PHP requests, 5 threads to handle a
particular
Of course they are kludges
Well, there we have it, an excellent argument for not adapting these
particular patches.
With every version we have bunch of things not working, openssl comes to
mind,
modules and drivers API changed. So this argument do not hold water.
Well, no. The less complex
On Tue, Aug 17, 2004 at 02:42:58PM -0700, [EMAIL PROTECTED] wrote:
With every version we have bunch of things not working, openssl
comes to mind, modules and drivers API changed. So this argument
do not hold water.
Well, no. The less complex the software we're maintaining, the fewer
On 2004.08.17, Andrew Piskorski [EMAIL PROTECTED] wrote:
On Tue, Aug 17, 2004 at 01:32:23PM -0700, Jim Wilcoxson wrote:
The reason thread pools would be interesting to me personally is to be
able to control quality of service better. For example, I may want a
pool of 5 threads to handle
[EMAIL PROTECTED] wrote:
On Tue, Aug 17, 2004 at 01:32:23PM -0700, Jim Wilcoxson wrote:
The reason thread pools would be interesting to me personally is to be
able to control quality of service better. For example, I may want a
pool of 5 threads to handle search engine spidering requests, and a
56 matches
Mail list logo
