Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
News server
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==News server attributes== Among the operators and users of commercial news servers, common concerns are the continually increasing storage and network capacity requirements and their effects.<ref name="Administering Usenet" /> Completion (the ability of a server to successfully receive all traffic), retention (the amount of time articles are made available to readers) and overall system performance. With the increasing demands, it is common for the transit and reader server roles to be subdivided further into numbering, storage and front end systems. These server farms are continually monitored by both insiders and outsiders, and measurements of these characteristics are often used by consumers when choosing a commercial news service. === Speed === Speed, in relation to Usenet, is how quickly a server can deliver an article to the user. The server that the user connects to is typically part of a server farm that has many servers dedicated to multiple tasks. How fast the data can move throughout this farm is the first thing that affects the speed of delivery.{{citation needed|date=August 2020}} The speed of data traveling throughout the farm can be severely bottlenecked through hard drive operations. Retrieving the article and overview information can cause massive stress on hard drives.{{citation needed|date=August 2020}} To combat this, caching technology and cylindrical file storage systems have been developed. {{citation needed|date=August 2020}} Once the farm is able to deliver the data to the network, then the provider has limited control over the speed to the user. Since the network path to each user is different, some users will have good routes and the data will flow quickly. Other users will have overloaded routers between them and the provider which will cause delays. About all a provider can do in that case is try moving the traffic through a different route. If the [[Internet service provider|ISP]] has limited connectivity to the network, routing changes may have little effect. Frequently a user can reduce the impact of network problems by using multiple connections. Some servers allow as many as 60 simultaneous connections, but this varies widely based on the provider.<ref>{{cite web |title=Usenet Server Connections Explained |url=http://www.techsono.com/usenet/faq/server-connections |publisher=TechSono Engineering |access-date=July 28, 2020 }}</ref> ===Article sizes=== Article sizes are limited to what each news server will accept. The larger the article size, the more space it occupies, and thus the fewer articles on each server. This generally means that a server can run with less overhead which makes for a more efficient server, but gives less articles for users to access.{{citation needed|date=August 2020}} ===Retention=== Retention is simply defined as how long the server keeps articles.<ref>{{cite web |title=Usenet Newsgroups Retention |date=16 May 2020 |url=https://www.usenet.com/usenet-newsgroups-retention/ |publisher=Usenet.com |access-date=July 28, 2020 }}</ref> Historically, most users want retention to be long enough so that they don't need to access the server every day but not overly long retention that can overwhelm users with slow computers or network connections.<ref name="Usenet The Other Internet" /> In the modern era, high speed connections, large storage capacity, and advanced search tools allows users to utilize extensive retention without any drawbacks. Retention is generally quoted separately for text and binary articles, though it may also vary between different groups within these categories. The times vary greatly according to the amount of storage available on the servers and continually increasing traffic. As of 2009, it is common for average news providers to have text retention of over 1000 days and binary retention of over 200 days.{{citation needed|date=August 2020}} Large news providers offer text retention up to 2480 days and binary retention of 850 days or more.{{citation needed|date=August 2020}} It's important to understand that retention time varies between different newsgroups within the text and binary categories. Omicron's HW Media is currently the Usenet server with the highest amount of binary retention, while Google is the Usenet server with the highest amount of text retention.{{citation needed|date=August 2020}} It can be difficult for end users to accurately measure the retention of a server. One common method is to examine the oldest articles in a group and examine the date, but this is not always accurate. Some articles in a group may be retained for longer than others, articles from remote servers do not always arrive promptly, and at times the date headers are simply incorrect. A sampling of many or all articles, preferably in more than one newsgroup, is required to detect such anomalies. News servers do not have unlimited storage, and due to this fact they can only hold posts for a length of time before they must delete them in order to make room for new posts. This is a particular problem to [[Newsgroups#Binary|binary newsgroup]]s which transmit large volumes of articles. For news servers provided by [[Internet Service Provider]]s as part of a user's subscription package, typical retention rates are usually only 2β4 days.{{citation needed|date=August 2020}} To deal with the increase of Usenet traffic, many providers turn to a hybrid system, in which old articles not found on the provider's server will request the article from another server with longer retention. ===Completion=== Given the large number of articles transferred between servers and the large size of individual articles, their complete propagation to any one server farm is not guaranteed. The term "completion" is used to describe how well a service is keeping up with the traffic.{{citation needed|date=August 2020}} The primary obstacle to calculating the completion percentage is how many articles were posted. Looking at only one server, one cannot know how many articles were actually inserted throughout the network.{{citation needed|date=August 2020}} Articles may never make their way outside the originating server, or may fail to find their way out to the transit cloud. Very large articles are frequently dropped, and tend to propagate less well than smaller ones.{{citation needed|date=August 2020}} One way to measure completion is to access multiple servers and retrieve lists of articles. Because Message-ID: headers are nominally unique throughout the network, comparison of the lists is mostly a straightforward task. Practical limitations to this type of measurement include the impossibility of obtaining lists from all servers worldwide, the fact that many servers filter out [[Spam (electronic)|spam]] or employ [[Usenet Death Penalty|Usenet Death Penalties]], and that some servers mask incompletion by hiding multipart binary sets with missing articles.{{citation needed|date=August 2020}} It is also necessary to take into account propagation times and retention; an article may simply have not yet arrived at a given server, or it may have been present but already expired. {{citation needed|date=August 2020}}
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)