pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] VDQ Re: Policy discussion: GNKSA


From: Duncan
Subject: Re: [Pan-users] VDQ Re: Policy discussion: GNKSA
Date: Mon, 4 Jul 2011 23:44:40 +0000 (UTC)
User-agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 9996aa7 branch-master)

Joe Zeff posted on Mon, 04 Jul 2011 14:26:27 -0700 as excerpted:

> On 07/04/2011 02:06 PM, Beartooth wrote:
>> And how will the GNKSA, ossified or not, and New Pan's take on the
>> GNKSA, affect things like the prestige of Gmane?
> 
> I gather that the maintainer would be willing to update the GNKSA if we
> were to come up with reasonable and well-reasoned suggestions.

That's interesting, as from the reply as mentioned in the other thread, I 
gathered that he saw it as primarily historical, and wasn't really 
interested in updating it, much as one (well, most "ones") wouldn't 
really be interested in "updating" something like the Roman Coliseum. 
(Restoring is a different matter entirely, perhaps the digital analogy 
would be more like ensuring proper archiving on the way-back machine, 
etc, not revising it.)

My fear, and I readily admit it reflects my potential status as a USENET 
"old codger", is that the GNKSA was one of the more authoritative 
references encouraging such practices as replying under the quotes, 
discouraging multi-page quotes with only a single line response, etc, and 
that busting it in the one respect we're considering here will 
effectively "bust the dam" in regard to all the others, as well.  So in 
practice, I see most of the GNKSA recommendations as still valid in 
general, tho perhaps a bit of tweaking would be fine.  (Actual point-by-
point analysis would come as part of my digesting the implications of 
this whole thing, something that I'm not mentally prepared to do ATM, but 
plan to within days or hours.)

It's this connections thing that is most problematic, and that IMO, has 
certainly been problematic since the turn of the century at least.  In 
fact, I'm not even sure it was ever valid, as written.

A bit of history in that regard is that MSOE abused all sorts of at the 
time commonly-accepted-wisdom in its news behavior.  It encouraged top-
posting, it encouraged HTML (to be fair, so did Netscape at the time, and 
so does Thunderbird today, I /think/, tho I use something else so I'm not 
positive on that), it broke signatures by omitting the space after the -- 
(because quoted-printable used a terminating space before the CRLF as a 
line continuation character and the OE devs apparently didn't want to or 
perhaps never event tried to code around the implications for their sig 
parsing), it broke the still common 80-char fixed-width assumption and 
requirement for some users, due to use of implied format=flowed... 
probably some I'm missing... AND of particular interest in our context, 
it abused connections by opening many and then making very inefficient 
use of them.

That's actually partly where the four connections per server limit 
originated for news specifically (tho it had roots in earlier proper 
netiquette connection limitations), because that is how many OE could 
open, and if the server allowed LESS than that, OE would spit out errors 
and fail to work right, thus greatly increasing support costs/hassles for 
whoever supported the server (ISP, NSP, volunteer running a server on a 
machine in his basement for a few text-groups-only...).  But then OE 
would only actually properly *USE* only a maximum of two, one for a 
batched download if a user set that up first, and a second if a user then 
interactively clicked on a post at a time to download it, with the 
ability to click on several before the first one actually downloaded, 
thus creating a queue for the second connection.  It was impossible for 
an OE user to actually use the four connections that OE needed to 
function correctly, to their fullest potential.

One can see a reflection of this in the wording for the connections 
requirement, where it emphasizes using connections EFFICIENTLY as well as 
only establishing four, maximum.

But certainly by the intro of Windows 98, which is when OE really got 
popular as it then shipped with the OS, any major news server had a 
server-side limit on the number of connections (at least, if they didn't 
verify user via login and charge by volume).  As a practical matter they 
had to, because most servers capped bandwidth per connection at the time, 
and users quickly figured out that more connections got around the cap, 
up to any limit the server imposed, so the server pretty much /had/ to 
impose a connection limit.  Plus, there were certainly script-kiddies 
around by then, that would, given the chance, open hundreds of 
connections and do little with them, just to DoS the server to death.

So the 4-connection-limit was IMO a bit of an anachronism even in the 
late 90s, perhaps by the time it was introduced, which was certainly 
after version 1.2 (January, 1995) which doesn't mention the word 
"connections" at all.  (Link courtesy of Wikipedia's GNKSA article.)

http://thecia.net/users/rnewman/Good_Netkeeping_Seal

And it's certainly an anachronism now.  If a new version of GNKSA is to 
be written, I'd say that instead of setting a connections max limit, it 
should recommend two things (SHOULD/recommend or MUST/require could be 
debated, I left it at the less strict SHOULD/recommend):

1) That a newsreader SHOULD allow the user to configure the number of 
connections independently per server, if it allows for more than a single 
connection (per server) at all.

2) That a newsreader SHOULD try to make the most efficient use of the 
configured connections possible.  IOW, none of this opening one 
connection only to update the newsgroups list and/or to see what the high-
and-low-water article numbers are, then leaving it idle, that was 
apparently the sole thing the that MSOE did with one of its connections.  
If a user has downloads or uploads queued and has less connections 
currently actively sending/receiving data than the user has configured, 
then the client should attempt to use existing or open new connections to 
the user configured limit and make use of them for the queued jobs.

A third one could be debated, too, tying into the current requirement

3) The pre-configuration default should be one/two/four connections per 
server.

(Four could be debated but it shouldn't be more than that.  A user could 
configure more if they wished.  AFAIK some servers only allow two, tho 
that was far more common before MSOE for the reasons explained above, so 
two could be argued to be the more conservative and better default; I'm 
not aware of any public servers still making only a single connection per 
IP available, but they may be out there.)

I don't believe a cap on the maximum number of connections is needed, 
because local application and machine resources will limit that to some 
degree, and anyone deliberately writing attach software or the like, the 
only reason I can think of to limit it beyond that, isn't going to be 
phased by such a recommendation/requirement anyway.  In general, it's a 
server-side policy issue that the client shouldn't need to deal with, 
except to allow the user to configure as many connections as the user 
wishes or the server might offer.


Meanwhile, I can mention that the http://gnksa.org home page mentions two 
mailing lists, gnksa-announce and gnksa-workers (just checked gmane, 
neither is carried there, at least with gnksa in the name, but gmane's 
head guy, Lars I. (IIRC a Norwegian name I'd have to copy/paste to get 
right), wrote something about news that favorably mentioned gnksa, that I 
found a link to somewhere, so he at least knows about it, I think I'll 
post a question to gmane.discuss to see if he has any suggestions).

Joe, as you've kindly volunteered to be a liaison, perhaps you could look 
into that and see if those lists are still active at all (it would have 
been nice if I could have simply checked gmane, but...), with the idea of 
posting a question to see if anyone still subscribed may be interested in 
a revision discussion (seems I'm adapting to the idea of revising it, 
already! =:^).

If there's any useful replies to such a question at all, the revision 
discussion should probably be moved to that list.  But if there's 
nothing... here is probably as good a place as any.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




reply via email to

[Prev in Thread] Current Thread [Next in Thread]