pure transit server

[Fabien Tassin]

According to Russ Allbery:
> 
> Fabien Tassin <fta at sofaraway.org> writes:
> 
> > I've converted quite easily my server to be multi-threaded. Lets call
> > this beast "inntd" for InterNetNews Transit(er?) daemon.
> 
> I should really write up the various thoughts I had about how to do this
> at one point or another.  (Does your version allow for filtering?  That
> was tricky to do in my mental model.)

Filtering is not excluded but is not in my current todo list.

> What I basically had was a swarm of NNTP listeners, one per incoming
> connection, that submitted history requests using reader/writer locks
> around the history code and then accepted articles, handing articles off
> to a queue.

exactly what's already done except for the final queue (and of course,
history which is actually only a kind of precommit cache). 
I don't know if this single thread handling the queue is needed.
I was thinking of way to address directly a CNFS buffer from an NNTP
thread. I was thinking to do so even without having the article in memory
but I start to think it is not a so great idea.

>  The queue would be harvested by a single thread doing
> filtering (which is pretty much forced by the way that most of the
> embedded languages deal with threading, but threading if properly designed
> shouldn't be too much of a bottleneck) and then handed off to be stored
> and sent to remote sites.

this requires to keep a lot of articles in memory which is something I
want to avoid, if possible. My current implementation using a kind of
traditionnal spool limits my memory footprint to 600KB (per thread but it is
difficult to know for the whole) while still beeing very fast.

> The sending part, the threaded innfeed, I pictured as a central article
> queue manager that dispatched the articles to the pending queues of
> individual sending threads, one for each remote site, with reference
> counting thrown in there somewhere so that one would know when to free the
> article.

you mean rewriting innfeed from scratch ? this is something I have supposed
invevitable.. Here is what I have in mind. Let inntd try to send articles
itself as soon as they are received and delegate them to innfeed when a peer
is not ready/alive or is overloaded.
My (purely mental) design for that is not very clear at the moment.
I was thinking to another set of NNTP threads (outgoing this time) each with
a list of ref counted mmapped articles (directly into CNFS buffers). These
lists will be in-memory borned fifos, ie articles enter the queue and they
will have three ways to leave it: a) beeing sent, b) being pushed out and
then delegated to innfeed if the queue is overloaded or c) being expired
(and then delegated to innfeed) if they are in the queue longer than a
expiration time.

> Storage required locks (since it's writing to disk files), but one should
> be able to get to the point where all CNFS buffers can be written to
> simultaneously.

right.

> > I wanted to directly use INN history and CNFS code but I don't think
> > they are thread-safe.
> 
> Both of them involve disk writes to shared data structures, so both will
> require locking to be added to make them thread-safe.

unfortunatly right too :)
 
> > I've first looked at the CNFS code but, ootch, how dense and fuzzy ! 
> > APIs over APIs, conf files over conf files.
> 
> Yes.  The storage API is really itching for a rewrite.

I don't think I need the storage API. I only want CNFS.
 
> > I'm currently looking at the dbz code but like CNFS and anything that
> > can be useful for me, it is too tied to libinn, autoconf and the like.
> 
> Much of libinn should already be threadsafe and the rest shouldn't be too
> hard to make that way.  The basic utility functions, like concat, xmalloc,
> error, and the like, should be reasonably thread-safe.

I wonder if libinn should not be splitted into 3 or 4 libs.
All INN binaries are linked with the big kitchen sink, even when they
only need xmalloc() or die().

> > About threading, I'm using Linux pthreads. I try to write portable code
> > (I'm not using autoconf yet) but threads are always a problem.
> > Thoughts ?
> 
> Pretty much nothing to be done there beyond trying it on several different
> platforms once it's written and porting.

As I will not have time to do everything alone, I wish to distribute my
code ASAP.

-- 
Fabien Tassin -+- fta at sofaraway.org