Re: ad-hoc wifi news transport

Ethan Carter <ec1828@somewhere.edu> wrote:

bp@www.zefox.net writes:
 

Ethan Carter <ec1828@gmail.com> wrote:

Toaster <toaster@dne3.net> writes:
 

Posting this here (was on comp.misc)
>
I was researching NNTP and came across this project:
>
https://github.com/nntpchan/nntpchan/
>
Using NNTP as a base protocol for other services. Personally, I think
it's a great idea, and it got me thinking.
>
Wireless ad-hoc mesh networks are an interest of mine. Normally the
purpose of the network is to route traditional TCP/IP protocol stacks
on top of whatever routing technology (like babel). But for radios,
they broadcast out naturally, it seems like a service like news/store
and forward message sending would be a natural fit.
>
The idea is to use a smart flooding algorithm, like uflood
(https://pdos.csail.mit.edu/~jaya/uflood_thesis.pdf) and skip all the
routing/high speed packet delivery problems and just flood news
articles over it. I think it would be a good fit.
>
Usenet is already decentralized, decentralizing the infrastructure seems
like a cool idea. If I were going to do it, I'd add some kind of
proof-of-work scheme to prevent spamming the network. Bandwidth would
be low due to the air-time of a large mesh network being saturated, but
I see that as a plus, prevents abuse (spamming binaries on the net).
>
It's half baked, but I wanted to put my thoughts out there and see if
other work has already been done on something like this.

 
Everything in your post looks interesting, but I'm reading it all for
the first time.  I would have liked a slower presentation of everything.
For instance, nntpchan.net is down.  I'm asking for help on their IRC
channel at Rizon.  It's not clear what it aims to achieve, but it looks
interesting.
 
What I'm working on right now is an NNTP server for a small community.
So far the server is not able to peer itself with another one.  Where am
I going?  I see a lot of websites hosting forums.  That's the wrong
thing to do.  These forums should have an interface-independent storage
that provides the data for a web interface as well as others such as
NNTP itself.
 
I'm beginning the work with the NNTP protocol because it allows us to
use the system right away with all the NNTP clients out there.  But I
plan to build an HTTP API with which people can build their web
preferred web interface and then power their communities.
 
But I'm aware you're talking about something considerably lower level
here---which is also interesting.  Perhaps I could keep the idea in mind
while I work on this project.

>
To a degree, ad-hoc wifi bears some resemblance to the dialup connections
used in the days of UUCP. I wonder if a UUCP-like approach, at some level
in the stack, might be useful.

 
A UUCP approach sounds nice for peering.  Now, typically servers would
peer by plain TCP, so the server should plan for a UUCP-type of exchange
ahead of time.  I am not there yet, but I'll keep that in mind.  I
believe a UUCP-type of exchange might be too much for a first release
with peering support.  I also think we should take advantage of what's
available.  I think TCP plus NNTP is what the most popular servers do.
 

AIUI, NNTP relies on always-on, always-same network connections.

 
I think a server can come online, fetch all articles their peers want to
deliver and then disconnect.  But, yes, I think peers register their
peers and communicate with the same ones always.  I don't think we
should go towards a discovery of peers, say.
>

With UUCP administrators agreed to peer offline, since online hadn't been
invented yet . I don't see why that couldn't be automated, maybe through
some simple yes/no approval by an appropriate sysadmin


One of the nice things about UUCP is that it doesn't require any sort
of administrative hierarchy. It predates DNS, so there's no "master"
authority. Just a bunch of hosts configured to share messages when
there are messages to send and a path available to the next hop in
the path. Hosts were identified by a name at the end of "bang" list:
Something like ucbvax!agate!joesworkstation. Ucbvax would be a host
generally known how to contact, agate could be any host (typically
closer) that knew how to contact joesworkstation.

I don't think it required unique hostnames, though they were preferred,
since the bang paths generally were different for different hosts even
if the had the same name. In a sense the bang path was the identity of
any given host.

UUCP died out because DNS and ICANN made TCP/IP much easier to administer
and was incomparably faster. With with some thought it might be useful
again.

Thanks for reading,

bob prohaska