Just after Sympatico dropped NNTP I signed up for teranews.com. They
are pretty good for reading BUT I can go days not being able to post.
Right now it has been almost a week.
I also experimented with aioe.org. They seem great at posting but
terrible at reading.
Currently I use FreeAgent as my client and I read from teranews then
reconfigure the server to aioe in order to post then back again to
read.
To be honest I would buy the minimal Teranews package but their
intermittent service is stopping me as the minimal package uses the
same free.teranews.com server.
Any opinions, view-points, solutions, rants, etc? :-)
Thanks!
--
------------------------------------------------
http://www3.sympatico.ca/dmitton
SPAM Reduction: Remove "x." from my domain.
------------------------------------------------
Maybe the guy who keeps posting that freetera = poop is right after all.
Sounds to me like you just have to wait for something that works to come
along. X-private used to be the best. They didn't censor anything
(nothing) i sure hope X-private makes a comeback. So does Chuck. I'm
using aoie right now but it isn't very good for crossposting to more than
3 newsgroups. Maybe Avi Freeman can come up with something for posting
and reading newsgroups. A lot of people have been complaining to Avi that
they are being "frogged".
>
> Well, has anyone found a good (free) NNTP service?
>
> Just after Sympatico dropped NNTP I signed up for teranews.com. They
> are pretty good for reading BUT I can go days not being able to post.
> Right now it has been almost a week.
>
> I also experimented with aioe.org. They seem great at posting but
> terrible at reading.
>
> Currently I use FreeAgent as my client and I read from teranews then
> reconfigure the server to aioe in order to post then back again to
> read.
>
> To be honest I would buy the minimal Teranews package but their
> intermittent service is stopping me as the minimal package uses the
> same free.teranews.com server.
>
> Any opinions, view-points, solutions, rants, etc? :-)
>
> Thanks!
>
Try asking in alt.freenewservers. And theres actually *more* trolling
there, so be advised.
Or you might try test posting (to alt.test *only* of course) with
servers you can find on these DNS's:
There *are* two or three that require an email registration, but they
only seem to last 6 months or so.
--
(setq (chuck nil) car(chuck) )
I've been using aioe ever since Sympatico blocked Ontario customers
from accessing the Aliant NNTP server.
I find it VERY fast at reading and updating / refreshing subject
headers and in pulling down the posts. Hardly any difference vs when
I was connecting to sympatico's server over a year ago.
If you're experiencing latency while reading, check your DNS server
setting (I use 4.2.2.2) and maybe try a different reader (there's
probably nothing better than Netscape Communicator 4.79).
Also, try hardcoding AIOE's IP address into your newsreader's NNTP
server setting - which is 194.177.96.26.
Well, I'm back to trying aioe.org exclusively. It seems much better
than the last couple of times I used it. Maybe I hit it (previously)
on a bad day(s).
A *lot* of nntp server admins don't like people accessing them by IP
address - too much resemblance to alt.2600 script kiddies I guess.
> Some Guy <So...@Guy.com> wrote:
>
>>Doug Mitton wrote:
>>
>>> I also experimented with aioe.org. They seem great at posting
>>> but terrible at reading.
>>
>>I've been using aioe ever since Sympatico blocked Ontario customers
>>from accessing the Aliant NNTP server.
>>
>>I find it VERY fast at reading and updating / refreshing subject
>>headers and in pulling down the posts. Hardly any difference vs when
>>I was connecting to sympatico's server over a year ago.
>>
>>If you're experiencing latency while reading, check your DNS server
>>setting (I use 4.2.2.2) and maybe try a different reader (there's
>>probably nothing better than Netscape Communicator 4.79).
>>
>>Also, try hardcoding AIOE's IP address into your newsreader's NNTP
>>server setting - which is 194.177.96.26.
>
> Well, I'm back to trying aioe.org exclusively. It seems much better
> than the last couple of times I used it. Maybe I hit it (previously)
> on a bad day(s).
>
Make sure you store headers for your subscribed groups. Maybe even store
articles. That can remove a *lot* of the pain for low retention servers.
> Well, has anyone found a good (free) NNTP service?
>
> Just after Sympatico dropped NNTP I signed up for teranews.com. They
> are pretty good for reading BUT I can go days not being able to post.
> Right now it has been almost a week.
>
> I also experimented with aioe.org. They seem great at posting but
> terrible at reading.
I use aioe.org and an off line news server leafnode. Leafnode downloads
all the articles for the groups I'm interested in, and then acts as a
news server. The result is lightning fast reading, no having to go over
the internet to get each article as I read them.
The cons are posts take as long as the "check" interval you set leafnode
to. I have it set to 10 minutes, which given the normal propagation speed
of usenet will make little difference.
I also allows me to change news servers without reconfiguring any of my
clients. Just one line in the leafnode config and I'm getting articles
from a different server.
TTYL
> > Also, try hardcoding AIOE's IP address into your newsreader's
> > NNTP server setting - which is 194.177.96.26.
> >
>
> A *lot* of nntp server admins don't like people accessing them
> by IP address
You're a moron.
A destination server has NO IDEA that you've accessed it directly via
IP vs a DNS lookup. Both types of access look the same to it.
> chuckcar wrote:
>
>> > Also, try hardcoding AIOE's IP address into your newsreader's
>> > NNTP server setting - which is 194.177.96.26.
>> >
>>
>> A *lot* of nntp server admins don't like people accessing them
>> by IP address
>
> You're a moron.
Now there's a nice opinion...
>
> A destination server has NO IDEA that you've accessed it directly via
> IP vs a DNS lookup. Both types of access look the same to it.
>
Wrong. biggulp.readfreenews.net (down right now) and it's admin who runs
octanews absolutely *hates* people who use raw IP addresses for reasons
that he *may* give you more insight into if you ask him. Mike Horwath is
his name.
> > A destination server has NO IDEA that you've accessed it
> > directly via IP vs a DNS lookup. Both types of access
> > look the same to it.
> >
>
> Wrong.
No, I'm right.
> biggulp.readfreenews.net (down right now) and it's admin who
> runs octanews absolutely *hates* people who use raw IP addresses
> for reasons that he *may* give you more insight into if you ask
> him. Mike Horwath is his name.
If you don't know the reasons then don't tell me I'm wrong.
The ONLY reason why someone would want you to use an FQDN instead of
an IP is if the IP is prone to changing from time to time and you
don't want to deal with support issues like "why can't I access your
server any more".
The server (any server - http, NNTP, etc) has NO IDEA how you were
directed to it. There is nothing for it to tell the difference if you
accessed it via an NS-lookup or direct to it's IP.
Say a news service has 6 news servers from 1.2.3.4 to 1.2.3.9
Say it uses DNS to do load balancing. If you always access via a single
IP, you defeat this.
And if they decide to take 1.2.3.7 offline for software upgrades,
testing, performance evaluation, whatever, they will definitely hate it
if customers still access it even though that IP is no longer in the DNS.
And I am not sure, but it is also possible that your news client would
use the ip address instead of the server name in some header lines and
this would not be very nice.
> A *lot* of nntp server admins don't like people accessing them by IP
> address - too much resemblance to alt.2600 script kiddies I guess.
?
> Wrong. biggulp.readfreenews.net (down right now) and it's admin who runs
> octanews absolutely *hates* people who use raw IP addresses for reasons
> that he *may* give you more insight into if you ask him. Mike Horwath is
> his name.
But how will he ever know?
trying to bring down IP's by doing them in order. Like wardialers used
to do.
> chuckcar wrote:
>
>> > A destination server has NO IDEA that you've accessed it
>> > directly via IP vs a DNS lookup. Both types of access
>> > look the same to it.
>> >
>>
>> Wrong.
>
> No, I'm right.
>
>> biggulp.readfreenews.net (down right now) and it's admin who
>> runs octanews absolutely *hates* people who use raw IP addresses
>> for reasons that he *may* give you more insight into if you ask
>> him. Mike Horwath is his name.
>
> If you don't know the reasons then don't tell me I'm wrong.
>
I *told* you the reason he told me and if you want a better answer, ask
him. I'm not going to put words in his mouth. He's active on usenet.
> The ONLY reason why someone would want you to use an FQDN instead of
> an IP is if the IP is prone to changing from time to time and you
> don't want to deal with support issues like "why can't I access your
> server any more".
>
> The server (any server - http, NNTP, etc) has NO IDEA how you were
> directed to it. There is nothing for it to tell the difference if you
> accessed it via an NS-lookup or direct to it's IP.
>
--
What is the issue here?
Do you agree that the server won't know that you accessed directly via
IP vs indirectly via nslookup?
Yes, there are issues using only the IP. But if we're talking about
trying to obtain the BEST performance, then the direct IP will give
you the BEST performance (best speed, lowest latency).
No you didn't. You just said that some guy didn't like hard-coding
the IP of his server. No reason was given why he didn't like it.
> and if you want a better answer, ask him. I'm not going to put
> words in his mouth. He's active on usenet.
He supposedly gave you no reason. So why are you babbling about it?
Go ask him why and come back and tell us what he said. Otherwise you
have no counter-argument.
Not unless the one IP you are using happens to be the busiest news server.
Not if that particular IP points to a server that is down for maintenance.
Not if that particular IP points to a server running massive cleanup
jobs and is extremely slow.
> > But if we're talking about trying to obtain the BEST
> > performance, then the direct IP will give you the BEST
> > performance (best speed, lowest latency).
We were talking about the AIOE server, so:
> Not unless the one IP you are using happens to be the busiest
> news server.
To my knowledge, AIOE operates only 1 server
> Not if that particular IP points to a server that is down for
> maintenance.
If the AIOE server is down, then using DNS won't help you either.
> Not if that particular IP points to a server running massive
> cleanup jobs and is extremely slow.
If the AIOE server is doing a "cleanup" then using DNS still won't
help you.
And there have been times when my DNS server has been slow or
"broken". So hard-coding the IP is one way to avoid DNS issues.
If you or anyone else regularly connects to a certain server using a
certain app, then you can test the direct IP method yourself FOR THAT
APP, FOR THAT SERVER, and see if it's faster. You can always go back
to DNS.
If you're trying to diagnose latency or poor performance issues, then
temporarily hard-coding the IP will tell you if an over-loaded or
poorly-performing DNS server is responsible.
>>> A *lot* of nntp server admins don't like people accessing them by IP
>>> address - too much resemblance to alt.2600 script kiddies I guess.
>>
>> ?
>>
>
> trying to bring down IP's by doing them in order. Like wardialers used
> to do.
Like DOS attack?
But you can do that via the domain name too - in fact the server won't know
the difference - since the domain name is transparent to the server.
> chuckcar wrote:
>
>> > A destination server has NO IDEA that you've accessed it directly via
>> > IP vs a DNS lookup. Both types of access look the same to it.
>> >
>> >
>> Wrong.
>
> No, I'm right.
>
>> biggulp.readfreenews.net (down right now) and it's admin who runs
>> octanews absolutely *hates* people who use raw IP addresses for reasons
>> that he *may* give you more insight into if you ask him. Mike Horwath
>> is his name.
>
> If you don't know the reasons then don't tell me I'm wrong.
>
> The ONLY reason why someone would want you to use an FQDN instead of an
> IP is if the IP is prone to changing from time to time and you don't
> want to deal with support issues like "why can't I access your server
> any more".
>
> The server (any server - http, NNTP, etc) has NO IDEA how you were
> directed to it.
In the case of NNTP I believe you are correct, I don't believe there is a
mechanism available for the server to determine what name you used for
lookup, but I could be wrong.
However, for http you are incorrect. There is a mechanism in the http
request the allows the server to determine which name was used for
lookup. This is one way "virtual web servers" work, the technique is
called "name routed" or "name based" web hosting (the other technique is
IP aliasing where a single physical machine has multiple external IP
addresses).
The http GET request contains a field called "HOST" which contains the
name of the website the client is requesting.
For more info:
http://www.apnic.net/info/faq/virtualwebfaq.html
TTYL
I didn't say it was a *bright* way to do it, just an easy way.
> In the case of NNTP ..., I don't believe there is a mechanism
> available for the server to determine what name you used for lookup,
> but I could be wrong.
You're not wrong. The NNTP service never receives a hostname from the
client.
> However, for http you are incorrect.
Not exactly. HTTP might provide a way for the client to request access
to a particular virtual host, but that does not mean that the client
connected to the server by looking up that hostname (though in normal
use that is what would happen, in the context of this discussion, it
need not necessarily happen that way).
> The http GET request contains a field called "HOST" which contains the
> name of the website the client is requesting.
Indeed but try an experiment based on the following on a system hosting
a web server that does virtual hosting:
telnet 127.0.0.1 80
GET / HTTP/1.1
host: ${virtualdomain}
The response you'll get would be the same as a browser would have gotten
if it had bee directed to http://${virtualdomain}/. Now try:
telnet ${virtualdomain1} 80
GET / HTTP/1.1
host: ${virtualdomain2}
You'll get back the page for ${virtualdomain2} even though your
connection was established using the name of ${virtualdomain1}.
The connection between computers is made by IP address only. Hostnames
exist for the benefit of human beings. Any client software that is given
a hostname to connect to must first convert that hostname into an IP
address before it can try to connect. DNS is the service that provides
that conversion, and the connection is then made by the IP address.
This discussion has been quite silly, of course: those that argued
that the server being connected to has no way to determine whether
the connection was initiated using a hostname or an IP address have
been correct all along. The only perceived speed increase in using
an IP address instead of a hostname is in the elimination of the DNS
query that would be required if a hostname were used, but the potential
inconvenience of having a service move from one address to another (or
in the case of DNS-based load balancing as one earlier poster suggested)
makes that perceived speed increase not worth the effort (that would be
required to ensure the hard-coded address were kept up to date).
I hope this helps clarify the matter ...
--
----------------------------------------------------------------------
Sylvain Robitaille s...@alcor.concordia.ca
Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Doesn't the client normally generate a message ID with @servername
tagged to it ? In this case, the client would be submitting an NTTP post
containing a header which would have a message ID @ip_address instead of
@server_name.
This has some implications for archival issues (like google) where 3
years from now, you may have no clue on who that IP belonged to at the
time the post was made.
In terms of HTTP requests, the connection may be done by IP only, but
the web server,s configuration may require an explicit proper host name
and may not provide any content of value if you try to access it with
http://ip_address
A good example:
It gives significantly different results than
> Doesn't the client normally generate a message ID with @servername
> tagged to it ?
How the client creates the message-ID is implementation-specific, and
has nothing to do with whether it is configured with a hard-coded IP
address for the server, or a hostname.
See the message-ID of any of my messages, for example. That's the
client's hostname, not the server's. It also is not used by the NNTP
server in any way that distinguishes between hostnames and IP addresses
(message IDs are expected to be unique, and they're used in the exchange
of messages between news servers, but the news server doesn't care if
the content of the message-ID contains its own hostname or IP address or
not).
> This has some implications for archival issues (like google) where 3
> years from now, you may have no clue on who that IP belonged to at the
> time the post was made.
What implications? What difference does it make what the Message-ID
*claims*? Keep in mind that the message ID is an arbitrary string, with
very few restrictions other than that it should be unique.
"echo `date`.$$ |md5sum" can give you a guaranteed unique string for a
given system, and if you add another string to it that is unique to that
system (such as the primary network interface's MAC address) you have a
guaranteed unique message-ID which incorporates neither a hostname nor
an IP address. You'll be able to find the message, though.
The message-ID is implementation-specific. Usually, if you see a
message-ID with the NNTP server's hostname in it, it was added by the
server because the message arrived without a message-ID. Not always,
though. Some clients to use the server's name in their own message-ID
strings. That's a poor implementation, though, since the client can't
ensure that the string it's creating is unique (unless it uses some
other way to ensure that it is).
> In terms of HTTP requests, the connection may be done by IP only, but
> the web server,s configuration may require an explicit proper host name
> and may not provide any content of value if you try to access it with
> http://ip_address
Re-read my previous post. The experiment I proposed shows that
regardless of whether you use a hostname to establish the connection,
what the web server cares about is the hostname you give in the "host:"
header of the HTTP request. Normal HTTP clients will give the same as
the hostname in the URL they were directed to, of course (which,
incidentally, they looked up in DNS to get the IP address to connect
to), but they don't specifically need to (except that if they didn't the
user would often not see the expected content).
> A good example:
>
> http://209.195.118.104
>
> It gives significantly different results than
>
> http://www.istop.com
Ok, but go back to my proposed experiment and try:
telnet 209.195.118.104 80
GET / HTTP/1.1
host: www.istop.com
What do you get back?
Yes, but you are cheating here !
On a web browser, when you type http://www.chocolate.com/recipes/mousse.html
the browser extracts the host name as the first token after the // and
uses that to build the Host: header line.
If you type
http://209.195.118.104/recipes/mousse.html then the browser will build
a Host: 209.195.118.104 and the web server will respond with a page not
found because either it doesn't have a mapping for that host name, or
has a mapping to a directory that doesn't have "recipes" as a
subdirectory etc.
So you are correct that at the TCPIP level, only the IP address matters.
But at the HTTP level, the host name matters.
> However, for http you are incorrect. There is a mechanism in the http
> request the allows the server to determine which name was used for
> lookup.
This only works if the browser passes the name in the header variables.
If the variable is not present, the server will not know.
So it's really a kludge of sorts ;-)
The "Hosts:" header line has been standard for quite some time. Even
since web servers have begun to support virtual domains, the Host:
header line has been basically required by browsers.
For companies that have just one domain (or related domains), they can
get away without a "Host:" header line in incoming requests by setting a
default html mapping when the Host is not present.
The "Host:" header line has been standard since the late 1990s if I recall.
> The "Host:" header line has been standard since the late 1990s if I
> recall.
Yes with HTTP 1.1.
All I'm pointing out is that the Internet inhernetly has no method of
determining if a user accessed using a host name or IP address.
HTTP Host, etc are hacks on top of the TCP/IP.
>> telnet 209.195.118.104 80
>> GET / HTTP/1.1
>> host: www.istop.com
>
> Yes, but you are cheating here !
I'm not cheating. I'm demonstrating a concept. Go back and re-read my
first post in this thread ...
> So you are correct that at the TCPIP level, only the IP address
> matters. But at the HTTP level, the host name matters.
Have you read this thread?
> HTTP Host, etc are hacks on top of the TCP/IP.
No, it's a hack at the application layer.
>> HTTP Host, etc are hacks on top of the TCP/IP.
>
> No, it's a hack at the application layer.
The application layer (#7) is on top of TCP/IP.
...one could look if there was traffic to the DNS server just before the NTTP traffic.
:)
> HTTP Host, etc are hacks on top of the TCP/IP.
I guess there could exist a hidden Host on a server?
I.e. one which doesn't have the corresponding DNS entry...
> ...one could look if there was traffic to the DNS server just before
> the NTTP traffic.
>:)
And how will the remote site do that? The remote site can't.
>> HTTP Host, etc are hacks on top of the TCP/IP.
> I guess there could exist a hidden Host on a server?
> I.e. one which doesn't have the corresponding DNS entry...
Yes, "hidden" hosts are often the case - i.e. virtual web sites. But this
is dependent on the browser reporting accurate host headers. As it's been
said over and over in this thread, host headers, etc are done at the
application layer and not inherently part of TCP/IP. Thus accessing a host
by IP vs. Host Name really makes no difference unless you factor in certain
caveats such as HTTP Host headers.
However, the result is likely to be cached by the user's resolver and
multiple subsequent queries will not generate queries to the NNTP provider's
DNS server.
--
Geoffrey Welsh <Geoffrey [dot] Welsh [at] bigfoot [dot] com>
Just when you think something is behind you, that's when it's in the
perfect position to bite you in the ass.
>> And how will the remote site do that? The remote site can't.
> The remote site can operate its DNS server.
>
Why would I point to the remote DNS. Do you know how DNS works?
If the address hasn't been requested in a while, your DNS server
will ask the remote one to resolve the address in its domain.
Absolutely - but how would you correlate that back to my IP request?
I could be making random requets. A another user may have made the request.
Could even be my ISPs DNS server updating it's cache?
Unfortunately the two systems are so disconnected I don't think there will
be a reliable way to correlate the data - especially from the clients are
from a busy network (i.e. Rogers/Bell/AOL/etc)