| |
PA2AGA > HDDIG 12.10.99 17:17l 173 Lines 7714 Bytes #-9721 (0) @ EU
BID : HD_99_257G
Read: DL6KCF GUEST
Subj: HamDigitalDigest 99/257G
Path: DB0AAB<DB0ZKA<DB0ABH<DB0SRS<DB0AIS<DB0NDK<DB0ACH<PI8JOP<PI8ZAA<PI8GCB<
PI8HGL<PE1NMB<EA7URC<PE0MAR<PI8VNW
Sent: 991012/1100Z @:PI8VNW.#ZH2.NLD.EU #:7524 [HvHolland] FBB7.00g $:HD_99_257
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA21157 ; Tue, 12 Oct 99 10:38:43 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00016354 ; Tue, 12 Oct 99 07:47:37 MET
Date: Tue, 12 Oct 99 07:44:26 MET
Message-Id: <hd_99_257G>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/257G
X-BBS-Msg-Type: B
> >work in practice? I don't know (yet) but may implement some
> >of them and find out.
>
> This has all been done already. As you write, mail gateways
> have existed for a long time. Bulletin-to-News gateways also
> exist. There has been one operating (on a Linux system) for
> years in the area over here, and I have also seen these systems
> in Germany. Most likely the system is available as free software.
>
> It works like you describe: a separate news (sub)hierarchy is
> created, with groups named after the SB xxxx field in the BBS
> message.
>
> Besides the usual startup problems (id's being scrambled and thus
> messages being duplicated when more of these gateways appear and
> they operate bidirectionally), it seems to work fine.
> Maybe you should add it to your BBS too...
I did about two years ago.
We have been running nntp as a forwarding protocol here.
(See previous posts).
--
... Hank
http://horedson.home.att.net
>.
------------------------------
Date: Sat, 09 Oct 1999 23:26:49 -0400
From: Don <dnelsch@neo.rr.com>
Subject: The BBS network and tcp/ip.
Hank,
Your plan appears to be only slightly different than what is happening
right now with the AX/IP Internet links. The only difference is that you
are proposing to use newsgroups through "gateway systems" as the file
transfer mechanism as opposed to using "direct" file transfer between "ham
radio" bbs stations which encapsulate the AX.25 protocol in TCP/IP frames
for transmission over the Internet. At least the current system does
preserve the MID/BID system so that duplicate messages are easily "caught"
and not retransmitted because the bbs still will recognize the AX.25 bbs
protocol.
The other concern that I have about your plan is that there is no apparent
way to limit the use of the network to licensed hams, thereby insuring that
commercial use and/or "spam" does not end up on ham radio linked bbs
systems. With the current AX/IP transfer mechanism, only those stations
properly authorized by the "gateway" systems have access to the ham radio
bbs system from the Internet.
I certainly have no problems if you choose to use TCP/IP and newsgroups
protocols over radio between the "gateway" stations except that it has been
my experience that TCP/IP has way more overhead than what the
run-of-the-mill 1200 baud links can handle in a crowded environment. I
also think it is unreasonable to expect the masses to rush right out and
buy the piece-parts for 56KB radio links. As I recall the history of
packet, 1200 baud was chosen because of the availability of the
off-the-shelf modem parts using the Bell 202 standard. The current run of
Rockwell/Lucent 56KB surface mount devices isn't too practical for the
average ham with a 100 watt American Beauty soldering iron! Nor do they
work 1/2 duplex as most ham stations require.
Do I have a better solution? Not yet. I'd hope the new rules on spread
spectrum emissions will encourage higher bit rate data radios. Maybe some
wizard will figure out how to tweak a Qualcom digital PCS radio into the
ham band and make packet fly! Let's face it, without the old converted
Motorola and GE radios, 2 meter and 440 ham bands would not be as popular
as they are today! The same thing can happen again, only this time high
speed digital!
Don, K8EIW
Hank Oredson wrote:
> A couple folks asked that I repost my specific suggestions
> on how to migrate the existing BBS network to the model in
> current use on the internet. Here they are again. Not well
> organized, a bit of babble, but specific ideas. Would they
> work in practice? I don't know (yet) but may implement some
> of them and find out.
>
> Each BBS network message type has an equivalent internet
> application and protocol. For the BBS network to interoperate
> with these applications and protocols we need some number
> of "gateway" systems which do the appropriate translations.
>
> 1) Bulletins map to net news and the nntp protocol.
> We need a set of newsgroups defined to map to/from the common
> BBS network topics. One solution would be to use newsgroups
> of the form alt.hamradio.<topic> where <topic> is the To:
> field of the BBS message. Thus we would have, for example,
> alt.hamradio.keps, alt.hamradio.sysop, alt.hamradio.all
> The "gateway" servers would move messages both directions
> using the obvious and simple mapping.
>
> 2) Personal messages map to standard email and the pop3/smtp protocols.
> We can use the obvious address mapping. I've run this kind
> of "gateway" server for years, using a version of JNOS.
> It works fine, and is already available.
>
> 3) NTS messages are an intersting case. They probably need to map
> to net news and the nntp protocol. We might use a newsgroup
> such as alt.hamradio.nts-traffic for this purpose. In this
> case the same "gateway" servers which handle 1) will suffice.
> Ideas welcome from the NTS folks on how we might handle this.
>
> Note that we do not need "permission" from NIS or anyone else to
> begin to implement this capability. Everything exists within the
> ham radio network and not within the internet per se. The model
> is designed to be compatible with internet standards for the obvious
> reason: those standards exist and are well tested. We should use them.
>
> For some of the standards, file transfer protocols also exist. For
> example email has pop3 and smtp as network data transfer standards,
> and RFC-822 (and it's various updates) provide a guide to the
> construction of a bulk transfer protocol. We already use this protocol
> as import/export between BBS systems of various kinds. The needed
> extensions to the standard set of headers are documented in the
> BBS specification. For net news two standard transports exist. One is
> a bulk file transport using the "ihave/iwant" scheme similar to
> what is called "X forwarding" in the BBS network. The needed mappings
> are obvious and should be simple to implement.
>
> All the above would require only a small amount of fairly simple
> programming effort on the part of the authors of the ham radio
> tcp/ip programs, and very little effort on the part of the authors
> of the ham radio BBS programs. The hard work is deciding on the
> details of how the mappings will work, and setting up enough
> gateway servers to attract users.
>
> One advantage of this scheme is that we could use it to link
> existing news groups in the internet directly to the ham radio
> BBS network, with bidirectional exchange of messages. Some might
> consider this a disadvantage because of the obvious possibility
> of abuse by both hams and non-hams. This possibility should not
> get in the way of creating and testing the technology.
>
> There is an interesting technique we could use to do this integration.
> If each "gateway" server ran a web server with a standard middleware
> API to a local database, then the task of programming the needed
> applications would be fairly simple. What applications are needed?
> Those required for the administration of the "gateway" server itself,
> for example, to maintain mappings, deal with exceptions, and all the
> other "sysop" type of activities.
>
> One could even consider creating a "regular ham radio BBS" using the
To be continued in digest: hd_99_257H
Read previous mail | Read next mail
| |
