Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comm.software.newsserver > #644

Re: Store-and-forward-Lösungen?

From Heiko Schlichting <heiko@cis.fu-berlin.de>
Newsgroups de.comm.software.newsserver
Subject Re: Store-and-forward-Lösungen?
Date 2025-10-15 08:58 +0000
Organization Freie Universitaet Berlin
Message-ID <ml961eF44dqU1@mid.uni-berlin.de> (permalink)
References <87plapy65h.fsf@vagabond.tim-landscheidt.de> <ml71f2FltigU1@mid.uni-berlin.de> <10cljn3$115ar$2@solani.org> <ml72edFm4aaU1@mid.uni-berlin.de> <10cm3s6$1o4a$2@rabbit.rsli.de>

Show all headers | View raw


Volker Englisch <eh41@selene.inka.de> wrote:
> Heiko Schlichting schrieb:
>> Ich schrieb ja, dass es schwieriger ist. Unmöglich ist es nicht, aber die
>> Auswahl ist kleiner. Und weil UUCP gegenüber NNTP für den Newstransport so
>> ineffiziert? ist, wird man auch weniger Peers haben. Angesichts der
>> geringen Mengen an Artikeln spielt Traffic heutzutage aber keine Rolle
>> mehr.
>
> Warum sollte UUCP ineffizienter sein als NNTP? Protocol t, und gut ists.

Weil NNTP normalerweise so arbeitet, dass vor dem Senden von Artikeln das
Ziel befragt wird, ob der Artikel bereits vorliegt.

Das passiert bei UUCP nicht, sondern man erhält immer alle Artikel - auch
die, die man bereits hat.

Wenn man dann einen Newsserver mit vielen Peers betreibt (in Spitzenzeiten
waren es etwa 200 bei uns), dann erhält man die gleichen Artikel sehr oft
und schickt diese auch sehr oft unnötig an die Peers.

Auch zu UUCP-Zeiten (Ende der 1980er und Anfang der 1990er Jahre) hatten
wir ja schon sehr viele Newspeers.

>> ? Anders als bei NNTP wird ja nicht ermittelt, ob der Zielserver den
>>   Artikel schon hat.
>
> Ist ja auch nicht nötig - oder? Bei UUCP werden die Newsbatches ja nach 
> Zeitplan vom Host generiert. Die News, die der Host über sein 
> NNTP-Peering erhalten hat, prüft dieser ja schon auf Dupes. Also müßten 
> die Batches für die UUCP-Clients schon "sauber" sein. Jedenfalls sehe 
> ich keine Logeinträge über Dupes auf meinem UUCP-System...

Dann trägt Dein System wenig zur Vermaschung des Usenet bei und hat nur
wenige Peers - im Extremfall nur einen. Das kann man in manchen Situationen
schon machen, aber entspricht damit aus Usenet-Sicht mehr einem Leser als
einem Newsserver.

Heiko

Back to de.comm.software.newsserver | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Store-and-forward-Lösungen? Tim Landscheidt <tim@tim-landscheidt.de> - 2025-10-14 13:17 +0000
  Re: Store-and-forward-Lösungen? Heiko Schlichting <heiko@cis.fu-berlin.de> - 2025-10-14 13:28 +0000
    Re: Store-and-forward-Lösungen? Marco Moock <mm+solani@dorfdsl.de> - 2025-10-14 15:37 +0200
      Re: Store-and-forward-Lösungen? Heiko Schlichting <heiko@cis.fu-berlin.de> - 2025-10-14 13:44 +0000
        Re: Store-and-forward-Lösungen? eh41@selene.inka.de (Volker Englisch) - 2025-10-14 18:13 +0000
          Re: Store-and-forward-Lösungen? Heiko Schlichting <heiko@cis.fu-berlin.de> - 2025-10-15 08:58 +0000
            Re: Store-and-forward-Lösungen? eh41@selene.inka.de (Volker Englisch) - 2025-10-15 18:08 +0000
      Re: Store-and-forward-Lösungen? Thomas Hochstein <thh@thh.name> - 2025-10-25 18:30 +0200
    Re: Store-and-forward-Lösungen? Thomas Hochstein <thh@thh.name> - 2025-10-25 18:30 +0200
  Re: Store-and-forward-Lösungen? Matthias Andree <matthias.andree@gmx.de> - 2025-10-15 01:51 +0200
  Re: Store-and-forward-Lösungen? Martin Burmester <martin@burmester.org> - 2025-10-18 16:20 +0200
  Re: Store-and-forward-Lösungen? Thomas Hochstein <thh@thh.name> - 2025-10-25 18:30 +0200
    Re: Store-and-forward-Lösungen? Marco Moock <mm+solani@dorfdsl.de> - 2025-10-25 20:31 +0200
      Re: Store-and-forward-Lösungen? "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-10-25 22:21 +0200
      Re: Store-and-forward-Lösungen? Friedemann Stoyan <usenet@ip6-mail.de> - 2025-10-26 03:45 +0100
    Re: Store-and-forward-Lösungen? Tim Landscheidt <tim@tim-landscheidt.de> - 2025-10-25 21:16 +0000
    Re: Store-and-forward-Lösungen? Martin Burmester <martin@burmester.org> - 2025-10-25 23:34 +0200

csiph-web