03 Oct 23: One server has been relocated, the server currently doesn't have a public IP address in the meantime. I wrote some additional tunnel code running separately to handle this. When the server is engaged the connection is 5600+ days uniform (since around 24 July 2008). In the unlikely case I disengaged the server because of some problem the retention is 1200-3800 days depending on newsgroup. If you experience any issue please let me know.
29 Nov 23: Because of encrypted and "obfuscated" flood mass posted by few nzb websites and newzbin-like communities using usenet servers as private storage for their members to download the posts - the situation with the content is pretty chaotic, since posts are disguised in such a way, that users must use the satellite ecosystem (whish is not a part of Usenet) exclusively to download them, when the website disappears - the encrypted scattered posts just eat usenet providers' disk space uselessly. If you can't find something specific please let me know what exactly you can't find for me to check how it is possible to retain the posts. Legible posts shouldn't be affected at all, let me know if you notice anything missing.
08 Aug 24: After being unchanged for many years the search service communication protocol had to be updated a few times in part to resolve a server side set feature limitation and properly handle trial searches on the relocated server. The searches themselves are not affected and it looks like the work is now complete.
15 Mar 25: It looks like the search service is currently down as there are no pings. The other server is no more on starlink, but the search requests are still routed and the access to it is through the first server, since it is safer, but the direct access is no problem if this will be a repeated issue. The connection will be restored or server restarted as soon as possible.
16 Mar 25: One server is currently still down, the other server was reconfigured and already connected directly, so the search service is running with minimum possible retention gaps.
if none works it is most likely your firewall or router to blame.
if one works and another doesn't it may be temporary connectivity problem from your ISP to the server, usually they are resolved at most within few hours.
When did you last do a search? I had to add a new IP to my firewall recently when I did a search so if you haven't searched in the past few days it could be that. Check your firewall if you have one: either disable it temporarily, allow UE full access or remove UE from the rules and try again. If you have a router, remove that and connect directly if you can to test.
yes, it must be some problem with router or firewall then.
i've sent you pm with more concrete diagnostics checks, something must not work with them. again the question is whether everything or only part doesn't work.
Found that I could telnet from my Lilnux machine, but not from Windows.
Both, of course, go through same firewall and router.
Noticed I had put dyndns entries in the "hosts" file on the Windows box a while back... why? I don't know (probably trying to get things to run a wee bit faster), I don't even remember doing it. They're gone now and all is well.
maybe i'll connect the search service ip resolution to UE caching dns capability as with news servers with resetting resolved ip after a socket error but using once resolved dns during current session as long as all is ok.
I am trying to use UE on my work PC, and I can download headers from GigaNews, using port 443 (SSL and open on our work network), but my searches are failing:
Search failed - A connection attempt failed because the connected party did not properly respond after a period of time
Is this a setup issue, or the search service not working?
The ports in use by the Search Service are (or at least were) 2020, 2021 and 2022. Check that they are open in any firewalls on the network. It's a pity UE doesn't use something common like port 80 to simplify matters.
KillerBob wrote:Is there a way to change the port for the Search Service?
There used to be but you could only change between the three I mentioned earlier anyway. Now it's all done dynamically. There may be some way of doing it through a proxy and port forwarding or the like. However, this would be a workaround and may or may not be reliable and, at best, slow.
The only sure way of doing this would be for the Search Service to use a more commonly open port. The advantage to using an HTTP port would be that you could then add UE.exe to a firewall using a web browser template (of which most firewalls have built in) which would then not be picky when it comes to IP address changes.