On Wed, 2004-08-18 at 09:21, Jim Wilcoxson wrote:
...
AOLserver is ideally suited to the majority of server tasks. About the
only shortcoming which comes to mind is that conn threads are required
to do blocking writes. But fixing that would be of benefit to the HTTP
processing side
Yep, there are always cases where any given solution won't work well.
Using the HTTP protocol to download a a 600MB CD image or to implement
a movie server, is clearly different than average web usage. To
display the _directory_ of the CD image, or download individual files,
output spooling would
On 2004.08.19, Jim Wilcoxson [EMAIL PROTECTED] wrote:
For fastpath (static file serving), reading a file into a memory
buffer would seem to scale well for typical web size images: 250K or
less, especially considering that fastpath already uses a memory
cache. I can see 3 scenarios:
1. File
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 vote for (a).
I read both discussions from the sourceforge-links you provided and I
see no jealousness or vanity between
Given the current movement of this thread in the direction of You're
wrong... no, you are!!, I figured I'd toss something out in an attempt
to set it back on track a bit.
What, exactly, is the goal that we are trying to accomplish by applying
one of these patches? Can we put together a list of
On Wednesday 18 August 2004 16:43, Robert Seeger wrote:
Given the current movement of this thread in the direction of You're
wrong... no, you are!!, I figured I'd toss something out in an attempt
to set it back on track a bit.
What, exactly, is the goal that we are trying to accomplish by
Jim Wilcoxson wrote:
IMO it is not scalable to use connection servicing threads to spool
output when the size of the output exceeds the socket buffer capacity.
Doing I/O with non-blocking, event-driven threads also helps prevent
DOS attacks. The trade-off is in memory usage: when a connection
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
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 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
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
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
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
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:
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
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 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
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
49 matches
Mail list logo
