OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

IW8PGT

[Mendicino(CS)-Italy]

 Login: GUEST





  
UT1HZM > PACKET   01.03.23 10:41l 52 Lines 1796 Bytes #999 (0) @ WW
BID : 17966_UT1HZM
Read: GUEST
Subj: Re: Tips: WP Updates
Path: IW8PGT<I3XTY<IZ3LSV<DB0ERF<OK0NAG<OK0PBR<UT1HZM
Sent: 230301/0909Z 17966@UT1HZM.KREM.POL.UKR.EU BPQK6.0.23

Hi Red.

My comments below.

> 
> From: PE1RRR@PE1RRR.#NBW.NLD.EURO
> To  : PACKET@WW
> 
> 
> 
> For quite a few years now, The WP system has been able to handle
> direct (P-type) messages from peers on the network and some BBS
> software also have the capability to parse information directly from
> bulletins passing through the BBS to expand the local whitepage
> database without the need for WP updates at all.

Its not new, WP-system in most major BBS software learn user's
P-address info from bulletins that users send over network,
already for decades.

And developers of BBS s/w allows sysop to select to send that
update-info as we know two ways:

1) as flood bull WP@WW.
2) as directed P-message WP@BBSCALL
(in this way updates should send to bbs call of every direct fwd partner).

There are options. But problem: there has never been
a clear rule about which function to use!

Some operators decide that its simply send it as flood bull (1)
and don't bother about set it to send to just every forwarding partner. (2)

But there are no sense to send that flood WP@WW updates from
every BBS, if it take most of info from same source - general @WW, @EU etc bulls.


My opinion/plan for new-ideal WP-system:

1) by default BBSes should learn addresses from all of general bulletins its have;
2)   learn WP-info from new users inputs (new user registration).
3) WP-updates could generated as flood bull to WP@WW,
but only with new info learned from new local users input!
To avoid useless traffic of generation WP-updates from general bulletins.

With that scenario possible to minimize WP-traffic and simplification its exchange!
SP WP@BBSCALL updates - will not need at all and flood WP-bulls will be only generate
unique data, not duplicate each other (as we have now).


73, Sergej.


Read previous mail | Read next mail


 23.12.2024 12:33:35lGo back Go up