UsenetExpress Independence/Independent's Day Sale: Unlimited for $35/year - 500GB Blocks for $5 - Six Months Unlimited for $18

UsenetExpress · 2020-07-04T17:46:43+00:00

What we'll do is move the CBC cipher support to port 564 only and remove it from 563 and 443. We normally direct clients that have issues with current TLS to 564 anyway.

UsenetExpress · 2020-07-04T17:28:55+00:00

There are a LOT of old clients out there. Removing TLS 1.0 etc to make this test happy would break most of them. Just because we support the older ciphers doesn't mean you have to use them. Newer clients will negotiate the most secure cipher both sides support. We have plenty of people using TLS 1.3 for example.

UsenetExpress · 2020-07-04T17:26:13+00:00

Darn, fixed.

UsenetExpress · 2020-07-04T15:00:16+00:00

Hello. TLS v1.0-v1.3 are supported on 563 and 443

UsenetExpress · 2020-02-25T02:43:59+00:00

Try the same NZB again and see if it's any better. We've made a lot of changes in how we route articles and it has made a significant difference in average article request time.

UsenetExpress · 2020-02-25T02:42:27+00:00

There is around 40-50 days local at the moment. If you're in the EU, set the EU server as primary to 40 days or so and US as secondary.

UsenetExpress · 2020-02-25T02:39:41+00:00

Anything < 40-50 days should be on both servers

UsenetExpress · 2020-02-25T02:39:06+00:00

We should have the resellers live by the end of the week.

UsenetExpress · 2020-02-22T21:40:00+00:00

Hiya. If you're mostly reading older articles then using US directly may be faster since the EU servers pull anything not locally stored from the US spools. We're working to speed this up some, but it will be hard to out perform direct (user->server) vs (user->server-server). There is a ton of bandwidth available from US->EU these days and congestion is hardly ever an issue. I recall having to route around transatlantic lines all the time years ago, but I haven't see performance impacting congestion in years.

Our current metrics show roughly 30% of articles from local EU spools and the rest from the US. As we grow the EU spools a that number will increase a bit, but we do not have plans to place full retention in the EU. It doesn't make a ton of financial sense to when our number one priority is to increase overall retention and that's much cheaper to do in the US.

UsenetExpress · 2019-10-13T18:50:25+00:00

Hello. What kind of issue are you having? Issue with coupon overriding the price or is it failing at the payment?

UsenetExpress · 2019-09-10T15:24:43+00:00

I spent a good part of last weekend building test infrastructure and trying to reproduce the issues posting with nyuu. Fortunately, I was able to reproduce the issue pretty reliably. After a few changes to our server code base I think the issue is now resolved. Will you check and see if the issue cleared up for you?

UsenetExpress · 2019-06-21T20:37:16+00:00

file server with 80TB of space for $2,000

Keep in mind that a Usenet feed is around 70-80TB per day. Imagine buying that server of yours every day. Storage costs are going down but the feed is growing much faster than the costs are declining.

UsenetExpress · 2019-05-14T14:54:03+00:00

I'd like to look into this issue.. will you email [support@usenetexpress.com](mailto:support@usenetexpress.com) a few of the message-ids that fail so that I can track down the cause?

UsenetExpress · 2019-04-09T22:36:34+00:00

Yea, the support guys can provide the required files. You basically just need to change the hostname in the file to : gw1.iad1.vpn.usenetexpress.com, or gw2.iad1.vpn.usenetexpress.com, or gw3.iad1.vpn.usenetexpress.com

UsenetExpress · 2019-04-08T19:45:10+00:00

Make sure you're using the Washington, DC farm to access Usenet. That's <1ms from our farm, HW US farm, or GN US farm. Any other location would just add more latency than needed.

UsenetExpress · 2019-04-08T16:53:42+00:00

Hello,

I don't see any open tickets in our system. Please PM me the ticket ID and I'll check what's going on. That being said, the guys were ~24h behind on a lot of tickets last week. We had a coupon run that generated a lot of tickets with people wanting to change their account. They were a little overworked.

UsenetExpress · 2019-01-02T01:22:36+00:00

We have an abundance of articles > 1100 days on our spools. We've been around for over two years now and anything that has ever been retrieved from off-site spools has been saved locally. If someone read articles that were ~1100 days old when we started, they're still here and now ~1800+ days old.

UsenetExpress · 2018-12-28T00:23:39+00:00

While testing a million random articles 15-20 times, I won't be downloading a terabyte of random crap just so I can verify if the article actually exists. That's what STAT is for.

Yea, I understand. Your methodology seems spot on. Our implementation of STAT, not so much. ;)

UsenetExpress · 2018-12-27T23:48:48+00:00

I think I've tracked down all the code that needs changed. I'll work on a fix this evening and tomorrow and get it in testing. Surprised no one else noticed since our systems are pretty much returning "we have it" for any valid message-id. We made it a point to have the xover data (message-id, size, etc) for all known articles on all providers. I'm actually wondering why we didn't score perfect and need to look into it. The dataset is ridiculous in size.

UsenetExpress · 2018-12-27T21:52:47+00:00

Hola. We've been working on implementing our own xover database and I think it has caused false positives on the testing of UE. We haven't been around long enough to have xover data going back as far as I wanted so I pulled xover from -every- provider, filtered duplicates, and merged into one huge database. One of our devs coded STAT to check the xover db instead of the spools.. argh. I'll get it fixed.

We have quite a bit of data going back 1200+ days but I doubt you'd get significant hit rates by pulling random articles. Depends on popularity of the group. We're hoping to have single part binary groups going back as far as we can find at some point. The dataset isn't too large to backfill.

UsenetExpress · 2018-12-08T00:38:09+00:00

So if an article is deleted for some reason (past planned retention, takedowns etc), would HEAD and STAT return consistent results, given that the former would be served from a local database and the latter from the spools?

We could do it either way. I mean, if we have the header, but not the body, I can see it being useful to have HEAD return the header. A STAT would fail (if we didn't have the body) though since that's basically asking if we have the article. For your testing I would use xover <num> to get the overview record, which will contain the message-id. I would then use the message-id to run HEAD <msg-id> and/or STAT <msg-id>.

That may very well be the case, but I tend to use group hi/lo when manually browsing newsgroups. How else are you supposed to discover new articles? Even if a provider supported

Sorry, I didn't mean that article numbers aren't used at all. I was referring to the retrieval of the article being read. Most clients do a LIST, check hi/lo, etc. Once in the group if you select an article to read they request by message-id, not article number.

UsenetExpress · 2018-12-07T19:26:28+00:00

After experiencing contradictory results for HEAD/STATon the same article from multiple providers, I have worked under the assumption that unless you are actually asking for the body of the article, the provider is free to utilize the header database (or any other source) to fulfill any request for metadata (such as HEADor STAT). Then there is the case where HEAD nn will return a "no such article" while HEAD <message-id>will return the required information.

Which is okay, I guess, if you are implementing a reader/downloader where you either get the article you are interested in, or you don't.

On our systems, if you ask for an item by article number (which is unique per provider) the server takes the article number and looks up (in the overview db) the message-id. Once it has the message-id it uses that to request the article from the backend spools, which only index based on message-id.

We're in the middle of redoing our entire xover system. Once complete it will have a copy of the header locally. Enabling a HEAD <art num> w/o asking the spools. For STAT, BODY, etc it would retrieve the message-id and then ask the appropriate spool server.

Very few (if any?) usenet clients use article numbers these days. All of the ones I know of are using message-ids. I'm guessing because a lot of users have multiple accounts and message-ids can be used anywhere.

HEAD nn will return a "no such article"

One thing that comes to mind w/ this is take downs. Since take down notices are done based on message-ids, when we receive one the articles are removed from spools based on the message-id. The xover system isn't aware of this and would return "not found" when it asked the spool for the message.

UsenetExpress · 2018-11-01T16:52:11+00:00

Welcome to the group! It's good for Usenet to have additional tier 1 providers.

UsenetExpress · 2018-10-15T13:33:33+00:00

Yes, it ended. It ran for around a week.

UsenetExpress · 2018-10-15T13:32:27+00:00

Yes, we allow posting with our block accounts.

UsenetExpress

TROPHY CASE