How does this affect Usenet?
Have any prominent providers stopped allowing access from Russian
IPs or ASNs?
Looks like we’re going back to the Kremvax days.
Cogent, a major backbone / connectivity provider is de-peering Russian clients. So there is a good chance that Internet connectivity between
parts of Russia and other parts of the world will be less reliable if
not out & out broken (if more providers follow suit).
On 3/4/22 5:51 PM, meff wrote:
Cogent, a major backbone / connectivity provider is de-peering Russian clients. So there is a good chance that Internet connectivity between
parts of Russia and other parts of the world will be less reliable if
not out & out broken (if more providers follow suit).
Other big names in tech, particularly social media, are blocking
Russian clients.
We are witnessing what may be the first steps of a significant
fracture of the Internet, and thus in many ways, Usenet. The coming
days / weeks will show ho significant the fracture will be.
This is true and I'm certainly not a fan of what Cogent is doing. I
hope other backbones step up and use this opportunity to deploy more
links into Russia. Fracturing Internet connectivity this way is,
IMO, unacceptable.
I don't know how much of of a choice that Cogent, et al., feel like they have. It seems as if federal sanctions are forcing some companies
hands. If not directly telling them to disconnect, then by saying that payments for services rendered can't be conducted, thus causing
businesses bottom dollar to want to disconnect.
Keep in mind that the level of circuits that we are talking about could
be multiple thousands, if not tens of thousands, of dollars a month.
There's only so much generosity that can be had.
Interesting. Unlike the WWW though, Usenet was designed (back in the
Cold War, probably no coincidence) to be resistant to this sort of
thing.
We're seeing an interesting experiment. Wish Russia still had enough
Usenet readers to make it a worthwhile channel of communication.
I would say that it's more difficult to block dial up connections
between systems. But when an entire country wants to prevent
international phone calls, they probably have ways to do that.
Is it even possible to get a "phone line" anymore?
Most phone traffic these days just flows over VoIP right?
How do you know Usenet isn't accessible in Russia? Not doubting you,
just trying to figure out if it's true.
On 3/4/22 6:49 PM, meff wrote:
This is true and I'm certainly not a fan of what Cogent is doing. I
hope other backbones step up and use this opportunity to deploy more
links into Russia. Fracturing Internet connectivity this way is, IMO,
unacceptable.
I don't know how much of of a choice that Cogent, et al., feel like
they have. It seems as if federal sanctions are forcing some
companies hands. If not directly telling them to disconnect, then by
saying that payments for services rendered can't be conducted, thus
causing businesses bottom dollar to want to disconnect.
Keep in mind that the level of circuits that we are talking about
could be multiple thousands, if not tens of thousands, of dollars a
month. There's only so much generosity that can be had.
I wonder what the BBS / FidoNet is looking like these days.
Doing fine.
On 3/6/22 1:19 AM, Bud Spencer wrote:
Doing fine.
I have little doubt that they are functioning.
I wonder if they are seeing any mentionable change in traffic, either
up or down.
I wonder how well the BBS / FidoNet / other FTNs will do if they can't
make Internet / TCP based connections because of filtering that I'm
seeing some people talking about.
Will FTNs find a way to remain functional in the face of adversity?
Will their addressing scheme be flexible enough to allow significant
changes in routing? -- My limited understanding of FTNs is that they
tend to be hierarchical in nature. So can the FTN function if two
(root) zone's can't communicate with each other, but two deep nodes or
points therein can talk to each other? Can messages flow that way?
I've never had an option of getting sysop status, thus I can't say
about dynamics. I'll take a look (if I still can) to snapshot what's
going on, if you wish.
FTN is technically more like uucp.
Sure, netmail and arcmail may be routed and pushed instantly but it
doesn't have to.
As technology goes bundles will wait until picked up, may be never.
Back then, I've seen backlog was amassed for ten years.
There is that The Policy thing though. This might become an issue.
On 3/8/22 9:13 AM, Eric Pozharski wrote:
I've never had an option of getting sysop status, thus I can't sayI'm /curious/. But I'm not curios enough to invest more than about 5
about dynamics. I'll take a look (if I still can) to snapshot what's
going on, if you wish.
minutes of my time.
*SKIP*FTN is technically more like uucp.I agree that FTN is a batched / store-and-forward network like UUCP.
the FTN if you prevented the highest level systems from communicating.
Sure, netmail and arcmail may be routed and pushed instantly but itI speculate that netmail uses the Internet as a BBS-to-BBS
doesn't have to.
communications mechanism, probably contrary to the historic FidoNet
up, over, and down architecture that I'm referring to.
I'm not familiar with "arcmail".
On 3/6/22 1:19 AM, Bud Spencer wrote:
Doing fine.
I have little doubt that they are functioning.
I wonder if they are seeing any mentionable change in traffic, either up
or down.
I wonder how well the BBS / FidoNet / other FTNs will do if they can't
make Internet / TCP based connections because of filtering that I'm
seeing some people talking about.
Will FTNs find a way to remain functional in the face of adversity?
Will their addressing scheme be flexible enough to allow significant
changes in routing? -- My limited understanding of FTNs is that they
tend to be hierarchical in nature. So can the FTN function if two
(root) zone's can't communicate with each other, but two deep nodes or
points therein can talk to each other? Can messages flow that way?
On 3/4/22 10:13 PM, meff wrote:
Is it even possible to get a "phone line" anymore?
Yes.
But you have to ask yourself, what is a phone line?
Most phone traffic these days just flows over VoIP right?
Maybe.
It's almost certainly a /digital/ phone line. But that does not mean
that it's VoIP. The PSTN has been digital for decades. But ulaw / alaw
(64 kbps codec) used in the PSTN is decidedly NOT VoIP. The former will >happily carry faster (33.6 ~ 56 kbps) dial up modem connections under >questionable conditions while the latter struggles to do carry slower
(300 baud ~ 14.4 kbps) dial up modem connections under optimal conditions.
ISDN, both Primary Rate Interfaces (a.k.a. PRI) and Basic Rate
Interfaces (a.k.a. BRI) are completely digital and will happily carry
faster dial up modem connections. Many traditional PBXs / key systems
will support PRI and / or BRI interfaces.
In article <svv2sn$eno$1@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
On 3/4/22 10:13 PM, meff wrote:
Is it even possible to get a "phone line" anymore?
Yes.
But you have to ask yourself, what is a phone line?
Most phone traffic these days just flows over VoIP right?
Maybe.
It's almost certainly a /digital/ phone line. But that does not mean
that it's VoIP. The PSTN has been digital for decades. But ulaw / alaw >>(64 kbps codec) used in the PSTN is decidedly NOT VoIP. The former will >>happily carry faster (33.6 ~ 56 kbps) dial up modem connections under >>questionable conditions while the latter struggles to do carry slower
(300 baud ~ 14.4 kbps) dial up modem connections under optimal conditions.
ISDN, both Primary Rate Interfaces (a.k.a. PRI) and Basic Rate
Interfaces (a.k.a. BRI) are completely digital and will happily carry >>faster dial up modem connections. Many traditional PBXs / key systems
will support PRI and / or BRI interfaces.
While that's all true, I imagine that the centrally managed
telephone systems are more susceptible to severed links than the
Internet at large;
it's certainly more susceptible to wire-tapping by authoritarian dictatorships.
While that's all true, I imagine that the centrally managed
telephone systems are more susceptible to severed links than the
Internet at large;
Compared to the internet as originally intended, yes. But the modern >internet, with the small handfull of ISP's per geographical area, with
all customers connected in star patterns to those ISP's, has produced a >network wiring diagram reality that looks much like those "centrally
managed telephone systems" of old.
While that's all true, I imagine that the centrally managed telephone
systems are more susceptible to severed links than the Internet at
large;
it's certainly more susceptible to wire-tapping by authoritarian dictatorships.
The idea that dial-up is a viable alternative to the Internet to
circumvent censorship is a fantasy people tell themselves. To the
extent that it's effective at all, it's because the powers that be
can't be bothered to shut it off.
I explicitly withhold all education because nobody cares about it.
They will fare poorly.
Pretty much every FTN-style network is moving traffic over the Internet
these days, mostly on well-known ports.
The entire thing is based on a hub-and-spoke model, so while it
_can_ be point-to-point, most nodes send to a hub that then sends
to other nodes in the "network".
Again, this is pretty much all done over TCP/IP. Fidonet in particular
has relied on the Internet for trans-Atlantic communications since
1991; for all intents and purposes, FTN networks are applications
of the Internet, so cutting Internet access cuts off FTNs, as does
shutting down the hubs.
Most of the hubs are either running on home machines or VPSen
somewhere, and most BBS "sysops" are not particularly technical.
State-level actors easily could knock FTN hubs offline using DDoS
attacks, or just infiltrate the nodes and watch the (unencrypted and unauthenticated) traffic flow.
Some of the proponents will say, "but we can fall back to dial-up!"
But it is perhaps even easier to cut off dialup access than the
Internet. At that point you'd be better off using UUCP anyway.
Information /can/, and arguably /will/ flow. It will just be far more
text than video that people seem to have become accustom to consuming.
On 3/11/22 7:09 AM, Dan Cross wrote:
They will fare poorly.
:-(
Pretty much every FTN-style network is moving traffic over the Internet
these days, mostly on well-known ports.
I can't even pretend to be surprised that the Internet is the preferred transport.
The entire thing is based on a hub-and-spoke model, so while it
_can_ be point-to-point, most nodes send to a hub that then sends
to other nodes in the "network".
The hub-and-spoke nature surprises me more than a little bit.
Most of the hubs are either running on home machines or VPSen
somewhere, and most BBS "sysops" are not particularly technical.
State-level actors easily could knock FTN hubs offline using
DDoS attacks, or just infiltrate the nodes and watch the
(unencrypted and unauthenticated) traffic flow.
Huh, what's the motivating factor of running these BBSes then. Is it
just keeping-the-lights-on?
The thing about consuming video is that it's easy.
You don't have to learn to read to watch video.
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
While that's all true, I imagine that the centrally managed
telephone systems are more susceptible to severed links than the
Internet at large;
Compared to the internet as originally intended, yes. But the modern internet, with the small handfull of ISP's per geographical area, with
all customers connected in star patterns to those ISP's, has produced a network wiring diagram reality that looks much like those "centrally
managed telephone systems" of old.
Packet radio (eg. D-STAR) would be more difficult to control.
Though obviously open to jamming and location-finding, that would
at least be much harder than with phone lines, especially if using directional links.
Satellite internet is also an option if someone running it from
another country is willing to provide free access or there's a way
of paying for it from the afflicted country without getting locked up.
On 2022-03-11, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
Most of the hubs are either running on home machines or VPSen
somewhere, and most BBS "sysops" are not particularly technical.
State-level actors easily could knock FTN hubs offline using
DDoS attacks, or just infiltrate the nodes and watch the
(unencrypted and unauthenticated) traffic flow.
Huh, what's the motivating factor of running these BBSes then. Is it
just keeping-the-lights-on?
On 3/11/22 2:12 PM, Computer Nerd Kev wrote:
Packet radio (eg. D-STAR) would be more difficult to control.
Yep.
Though obviously open to jamming and location-finding, that would
at least be much harder than with phone lines, especially if using
directional links.
It's also illegal at the moment in Ukraine. They have temporarily
suspended amateur radio privileges. As such, I suspect it's illegal in
other countries to communicate with a ham in a location that's known to
be suspended.
But those are legality / paper tiger issues compared to can we establish >communications or not. Or at the very least, deal with them later,
after the immediate need for the communications is past.
On 3/11/22 7:09 AM, Dan Cross wrote:
[snip]
The entire thing is based on a hub-and-spoke model, so while it
_can_ be point-to-point, most nodes send to a hub that then sends
to other nodes in the "network".
The hub-and-spoke nature surprises me more than a little bit.
I would have naively assumed that there would be something closer to a
full mesh where systems could accept inbound connections.
I get systems that can't accept inbound connections would need to ""call
out to something else to retrieve messages.
[snip]
Some of the proponents will say, "but we can fall back to dial-up!"
But it is perhaps even easier to cut off dialup access than the
Internet. At that point you'd be better off using UUCP anyway.
Please elaborate on it being easier to cut off dial up access than the >Internet?
I would think that UUCP would be akin to dial up.
I can see one advantage of sticking with FTN over switching to UUCP. >Presuming that you were starting with FTN. Sticking with FTN would
maintain addressing. Conversely switching to UUCP (or anything else)
would change addressing and likely disrupt a lot of things.
On 3/11/22 7:01 AM, Dan Cross wrote:
While that's all true, I imagine that the centrally managed telephone
systems are more susceptible to severed links than the Internet at
large;
Probably. But I wouldn't bet more than a cup of coffee on it. It's my >understanding that the PSTN has become far more dynamic than it used to
be. As such, I expect that the majority of it can route around
problems. At least more so today than it could 20 / 40 years ago.
it's certainly more susceptible to wire-tapping by authoritarian
dictatorships.
The PSTN itself, probably. Things going across the PSTN, well that's
going to be far more dependent on what clients use.
The idea that dial-up is a viable alternative to the Internet to
circumvent censorship is a fantasy people tell themselves. To the
extent that it's effective at all, it's because the powers that be
can't be bothered to shut it off.
I feel the need to clarify that I'm talking about ad-hoc point-to-point
dial up connections between individuals. This is decidedly different
than the traditional dial-up ISP model. Think more akin to BBS / UUCP >systems / networks of yore. Especially if done from a notebook with a
modem as a road warrior.
Information /can/, and arguably /will/ flow. It will just be far more
text than video that people seem to have become accustom to consuming.
The funny thing is...
I mean, if I were in Kyiv or Mariupol right now, I'd be more worried
about an 82mm mortar round landing on QTH or a 120mm sabot round
coming through the window after DF'ing me than whatever the licensing authority has to say about pulling my ticket. But if I could call
in a fire mission on a T-72 in the open or confuse the Russians by transmitting nonsense on their freqs....
In theory, they _can_ do that. In practice, they tend _not_ to.
There are also two separable use-cases: netamil (basically, email) and echomail (roughly analogous to USENET). The former is more ammenable
to point-to-point mesh-style connections; the latter almost always
flows through a hub.
The Internet, by design, can route around broken links, and end
devices can usually take on any IP address they're configured with.
In contrast, a land-line telephone is tied to a physical location
and a single identifier. I could, in theory, plug my home network
into some kind of IP over RF network and it would work; not so much
my phone. Notably, at this point, most people's phones are little
radios anyway and speak IP natively.
Sorry, two separate thoughts; IF I were using dialup, I'd use UUCP
instead of FTN.
I think there are well-defined standards for translating between UUCP addresses and ARPANET style addresses. FTN? Not so much. Really,
FTN is poor technology and should be avoided.
Protocols like SS7 surely help, but the thing that has made it so
reliable is massive redundancy and centrally managed systems.
Yes, I understood that. What I'm saying is that that is just as,
if not even more, susceptible to suppresion, than the Internet.
In general, dial-up "networking" a la FTN is useless without the
Internet, and even easier to suppress.
Consider a BBS: someone has to be hosting it somewhere to dial into.
A state-level actor has any number of mechanisms to shut it down:
for instance, they could trivially rig up half a dozen phones to call
it continually, thus keeping the line perpetually busy; an analog
DDoS attach.
While it's true that point-to-point communications may not be attached specifically, the same is true of point-to-point data flow between Internet-connected computers. Moreover, to dial into some place,
I'm basically doing that from set physical location: no trampolining
through a VPS on the other side of the world, protected by a VPN.
There are cases in recent history of telephony networks being taken
offline at the behest of local governments, while Internet access
remained viable in some limited capacity. E.g., during the Arab
Spring. And while there were much-touted reports of people rolling
out BBSes talking to Fidonet to circumvent Intenet censorship, I've
never found any credible evidence that that _actually_ happened:
just people talking about it.
Moreover, almost all BBSes are completely unencrypted.
I suppose it's possible people could communicate real-time person
to person over dialup, but the reach would be seriously limited:
why not just talk on the phone?
Honestly, ham radio is probably much harder to silence, but carries
its own risks (direction finding and so on).
On 3/11/22 2:12 PM, Computer Nerd Kev wrote:
Packet radio (eg. D-STAR) would be more difficult to control.
Yep.
Though obviously open to jamming and location-finding, that would
at least be much harder than with phone lines, especially if using
directional links.
It's also illegal at the moment in Ukraine. They have temporarily
suspended amateur radio privileges. As such, I suspect it's illegal in
other countries to communicate with a ham in a location that's known to
be suspended.
But those are legality / paper tiger issues compared to can we establish communications or not. Or at the very least, deal with them later,
after the immediate need for the communications is past.
On 3/11/22 12:05 PM, Sn!pe wrote:
The thing about consuming video is that it's easy.
You don't have to learn to read to watch video.
Sure.
But what provides more information? A video that
you can't get to or reading text that you can get to?
On 3/11/22 7:08 PM, Dan Cross wrote:
The funny thing is...
I don't think there is anything funny about this. I will admit there is
some irony in what you said.
On 3/11/22 6:55 PM, Dan Cross wrote:
In theory, they _can_ do that. In practice, they tend _not_ to.
:-/
There are also two separable use-cases: netamil (basically, email) and
echomail (roughly analogous to USENET). The former is more ammenable
to point-to-point mesh-style connections; the latter almost always
flows through a hub.
But does echomail flow through a hub because it /needs/ to or by
convention / simplified configuration?
The Internet, by design, can route around broken links, and end
devices can usually take on any IP address they're configured with.
In contrast, a land-line telephone is tied to a physical location
and a single identifier. I could, in theory, plug my home network
into some kind of IP over RF network and it would work; not so much
my phone. Notably, at this point, most people's phones are little
radios anyway and speak IP natively.
ACK
Sorry, two separate thoughts; IF I were using dialup, I'd use UUCP
instead of FTN.
I think I too would use UUCP if I were to green field something. Not
the least of which is that I already have some UUCP, so extending that >network is fairly easy.
I think there are well-defined standards for translating between UUCP
addresses and ARPANET style addresses. FTN? Not so much. Really,
FTN is poor technology and should be avoided.
I largely agree. I was just thinking an existing, not /truly/ Internet >dependent network.
On 3/11/22 6:47 PM, Dan Cross wrote:
Protocols like SS7 surely help, but the thing that has made it so
reliable is massive redundancy and centrally managed systems.
ACK
Yes, I understood that. What I'm saying is that that is just as,
if not even more, susceptible to suppresion, than the Internet.
In general, dial-up "networking" a la FTN is useless without the
Internet, and even easier to suppress.
I don't agree.
I'm thinking of something akin to FidoNet of the days of yore where
there was no Internet and multiple BBSs formed the network.
Consider a BBS: someone has to be hosting it somewhere to dial into.
A state-level actor has any number of mechanisms to shut it down:
for instance, they could trivially rig up half a dozen phones to call
it continually, thus keeping the line perpetually busy; an analog
DDoS attach.
And what if the BBS is behind a different phone number each day? Or if
you can't use BBS #1, use BBS #2.
Maybe I'm asking too much of FTNs or thinking they can be made to be
more dynamic.
I do think that such could be done via UUCP between news servers. Each >server would flood messages to all the other servers.
While it's true that point-to-point communications may not be attached
specifically, the same is true of point-to-point data flow between
Internet-connected computers. Moreover, to dial into some place,
I'm basically doing that from set physical location: no trampolining
through a VPS on the other side of the world, protected by a VPN.
I'm thinking more a notebook computer with a modem that's moving from
place to place.
There are cases in recent history of telephony networks being taken
offline at the behest of local governments, while Internet access
remained viable in some limited capacity. E.g., during the Arab
Spring. And while there were much-touted reports of people rolling
out BBSes talking to Fidonet to circumvent Intenet censorship, I've
never found any credible evidence that that _actually_ happened:
just people talking about it.
ACK
Moreover, almost all BBSes are completely unencrypted.
True.
But the BBS is in many ways a means to an end; communications through
the network (FTN or otherwise) that is interconnecting them.
Also, individual messages can be encrypted, much like email, such that >someone without the decryption information only has (hopefully minimal) >metadata.
I suppose it's possible people could communicate real-time person
to person over dialup, but the reach would be seriously limited:
why not just talk on the phone?
Agreed.
Though it's probably easier to do voice encryption and exchange the data >therefrom.
Honestly, ham radio is probably much harder to silence, but carries
its own risks (direction finding and so on).
Yep.
Being mobile is key.
On 3/11/22 6:55 PM, Dan Cross wrote:
There are also two separable use-cases: netamil (basically, email) and
echomail (roughly analogous to USENET). The former is more ammenable
to point-to-point mesh-style connections; the latter almost always
flows through a hub.
Sorry, two separate thoughts; IF I were using dialup, I'd use UUCPI think I too would use UUCP if I were to green field something. Not
instead of FTN.
the least of which is that I already have some UUCP, so extending that network is fairly easy.
On 3/11/22 2:41 AM, Eric Pozharski wrote:
I explicitly withhold all education because nobody cares about it.That's demonstrably false because I care.
with <t0hh8o$3mh$1@tncsrv09.home.tnetconsulting.net> Grant Taylor wrote:
On 3/11/22 6:55 PM, Dan Cross wrote:[snip]
You two are avoiding one significant point of the puzzle. UUCP is fine
to move articles and files around. It doesn't handle subscription.
While FTN already has established way to communicate it (AreaFix and >FileFix). AIAUI, compatibility is good enough.
Give me text every time; trying to follow instructions on a video
is a total PITA. I fear that's another battle already lost, though.
In article <slrnt2p65p.50d.whynot@orphan.zombinet>,
Eric Pozharski <whynot@pozharski.name> wrote:
with <t0hh8o$3mh$1@tncsrv09.home.tnetconsulting.net> Grant Taylor wrote:
On 3/11/22 6:55 PM, Dan Cross wrote:
You two are avoiding one significant point of the puzzle. UUCP isNews software has handled newgroup messages and had regular
fine to move articles and files around. It doesn't handle
subscription. While FTN already has established way to communicate
it (AreaFix and FileFix). AIAUI, compatibility is good enough.
expressions for "subscriptions" for decades.
In article <t0hh8o$3mh$1@tncsrv09.home.tnetconsulting.net>, Grant
Taylor <gtaylor@tnetconsulting.net> wrote:
On 3/11/22 6:55 PM, Dan Cross wrote:
I largely agree. I was just thinking an existing, not /truly/FTN is not that, and it hasn't been for 30 years. BBS enthusiasts
Internet dependent network.
like to think that it could be, but I honestly think those people are deluding themselves.
gtaylor@, please stop beating this dead horse.
with <t0j4sq$pc$1@reader1.panix.com> Dan Cross wrote:
In article <slrnt2p65p.50d.whynot@orphan.zombinet>,
Eric Pozharski <whynot@pozharski.name> wrote:
with <t0hh8o$3mh$1@tncsrv09.home.tnetconsulting.net> Grant Taylor wrote: >>>> On 3/11/22 6:55 PM, Dan Cross wrote:News software has handled newgroup messages and had regular
You two are avoiding one significant point of the puzzle. UUCP is
fine to move articles and files around. It doesn't handle
subscription. While FTN already has established way to communicate
it (AreaFix and FileFix). AIAUI, compatibility is good enough.
expressions for "subscriptions" for decades.
I was misunderstood. I was trying to demonstrate The Apeal. The Apeal >doesn't check with reality though.
Sadly, that doesn't make it any less true.
Like I said, if you want to try and fall back to a dailup based
solution, you're better off with UUCP.
That makes it nearly undiscoverable.
I'm afraid you are.
Why would one choose to use something like FTN at that point, and
not UUCP or a more advanced technology that is interoperable with
the larger Internet? Is the point to shoehorn FTN into this role,
or to usefully share information?
Even "point to point" FTN requires the distribution of a nodelist
to every system in the network; without that, you can't usefully
communicate between nodes.
That implies that you need some mechanism to distribute the nodelist;
in some hypothetical system where BBSes are hopping from number
to number dynamically (where do these numbers come from, by the
way?) daily,
you've got a logistical problem keeping the network up to date.
And if that nodelist falls into the wrong hands, someone now has
a list of every BBS participating in this hyptothetical network.
Phone numbers are not anonymous, and while there _are_ things like
burner cell phones, it's not clear to me how you'd run a network of
BBSes with them.
Also, I imagine that once under occupation, burner phones are going
to become hard to come by.
Contrast with UUCP, where each node is configured only know about
its neighbors. You could trivially exchange PGP-encrypted mail over
UUCP; not so much with a BBS unless it's built into the BBS software
(though I suppose you could figre out some way to leverage "offline
readers" to download the mail and decrypt it locally).
UUCP as a dialup transmission mechanism does more than that but, yes,
if one were to try some kind of ersatz samizdat network over dialup telephony, UUCP would be the way to go.
So we are envisioning people with some kind of interface cable,
burner phone, and laptops clandestinely transmitting from cafes
or something?
I'm not sure how realistic that is under occupation, let alone an
active war zone.
The point is, why try to use an inferior technological mechanism like
FTN when UUCP is available? Trying to bend the former into something
useful seems like a heavy lift.
For that matter, why not try to do something like IP over RF instead?
Or even short messages sent over AX.25. Given that we know that
B-team Russian troops are using cheap consumer HTs on the 2m ham band,
one could conceivably put together a digipeater with a similar rig
and a Rasperry Pi with a battery in an ammo box unattended on a hill somewhere: it is unlikely to be jammed. A network of those could
easily make it into Poland where an igate could pick short messages
and redirect them to anywhere; even twitter.
A VPS somewhere that people could log into that's running a real
operating system (Unix or the like) would be more useful, IMHO.
As I mentioned above, to use a BBS for that, you need BBS software that
does it, which isn't super common. On the other hand, today one could
throw together a cheap Linux install on a Raspberry Pi with UUCP, GPG,
and mutt and make it work with as it would take to configure a BBS.
That's the hardest part in a combat zone.
On 3/13/22 10:53 AM, Eric Pozharski wrote:
gtaylor@, please stop beating this dead horse.
As a practicioner of old networking technologies for anyone that wants
to participate, I will continue to beat whatever horse that I want to,
dead or alive.
There is a very big difference in /what/ /could/ /be/ verses /what/
/is/. If people are not willing to spend the effort to convert from
/could/ /be/ to /is/ then that is on them. But their lack of effort
doesn't change what the technology is capable of doing.
On 3/12/22 8:47 AM, Dan Cross wrote:
Sadly, that doesn't make it any less true.
Please elaborate on why the Internet is required when a group of people
make dial up connections to each other using FTN and / or UUCP.
Like I said, if you want to try and fall back to a dailup based
solution, you're better off with UUCP.
Agreed. That's why I do use UUCP.
That makes it nearly undiscoverable.
/nearly/ is the operative word.
How many different things that want to hide from authorities rotate
where they are found at? As in they keep changing their location or
phone number? Does a "burner phone" mean anything to you? The long and >short is that those that need to know the current phone number will
either know it or know how to get it.
I'm afraid you are.
:-/
Why would one choose to use something like FTN at that point, and
not UUCP or a more advanced technology that is interoperable with
the larger Internet? Is the point to shoehorn FTN into this role,
or to usefully share information?
Even "point to point" FTN requires the distribution of a nodelist
to every system in the network; without that, you can't usefully
communicate between nodes.
It's been a long time since I've looked at the routing in FTN. But I >strongly believe that I don't need to have a list of every node in the
FTN. I /do/ need a list of every node that I directly communicate with.
The latter is decidedly a subset of the former.
That implies that you need some mechanism to distribute the nodelist;
in some hypothetical system where BBSes are hopping from number
to number dynamically (where do these numbers come from, by the
way?) daily,
You don't need to distribute / synchronize the entire node list.
You just need to distribute / synchronize the list of the nodes that you >directly connect to / call.
you've got a logistical problem keeping the network up to date.
Yes and no.
I believe that "eventual consistency" has a large hand in this.
I think that it's far more important to have information on the nodes
that I directly connect to / call than it is to have information on
nodes that are one or more hops away, much less on the opposite side of
the planet.
Consider the Default Free Zone in global BGP that makes up the Internet >today. It's in a constant state of flux. An *EXTREMELY* *TINY*
percentage of the routers that make up the DFZ have the same prefixes,
much less the same routes therefor.
You don't even need /eventual/ /consistency/. You just need
connectivity to adjacent / directly connected nodes to pass traffic
through and knowledge that you can route traffic for something further
away via a node you do connect with.
Changes are like ripples in a body of water, in that they have the most >impact closest to the ripple. The further you get away from it, the
less impact, if any, is perceived.
And if that nodelist falls into the wrong hands, someone now has
a list of every BBS participating in this hyptothetical network.
A very good reason to *NOT* have a complete list of phone numbers / >connection methods.
Phone numbers are not anonymous, and while there _are_ things like
burner cell phones, it's not clear to me how you'd run a network of
BBSes with them.
What is unclear about the /how/? The burner cell phone is tantamount to
a changing phone number. You just need the /current/ phone number of
the systems that you directly call yourself.
Arguably, you could get away with having the phone number of just one
single system as a boot strap to retrieve a list of other phone numbers
to call.
Also, I imagine that once under occupation, burner phones are going
to become hard to come by.
It also doesn't have to be a cell phone. It could be a phone extension
off of a phone system. Move a notebook every few days to a different >location with a different phone number.
You are bringing up things that are simply logistical challenges. None
of them mean that things won't / can't work. They just mean that it's >/harder/ to do. Harder != impossible.
Contrast with UUCP, where each node is configured only know about
its neighbors. You could trivially exchange PGP-encrypted mail over
UUCP; not so much with a BBS unless it's built into the BBS software
(though I suppose you could figre out some way to leverage "offline
readers" to download the mail and decrypt it locally).
I'll concede /integrated/ support for PGP (et al.). However /external/ >support for PGP has been the de facto for a long time. As in you copy
and paste ciphertext into / out of the BBS message editor and the PGP /
GPG implementation that you are using.
This is a hurtle at best. Definitely not a show stopper.
UUCP as a dialup transmission mechanism does more than that but, yes,
if one were to try some kind of ersatz samizdat network over dialup
telephony, UUCP would be the way to go.
Agreed.
I was naively assuming that FidoNet / other FTNs were /currently/ in a
better state for peer to peer dial up connections than UUCP.
If I were to green field something, I'd definitely use UUCP.
So we are envisioning people with some kind of interface cable,
burner phone, and laptops clandestinely transmitting from cafes
or something?
You're closer to what I describe above. The physical interface cable is >largely a non-issue for someone that wants to acquire it. Even most >contemporary cell phones can still act as modems and honor AT commands.
There's a good chance that you can even continue to use the same phone
with the same cable. Just trade the SIM cards. Or if you're worried
about tracking signature of the same phone's radio fingerprint, multiple >phones from the same model or that use the same cable.
I'm not sure how realistic that is under occupation, let alone an
active war zone.
Realistic is along the lines of logistics and practicality. They are >indifferent to the possibility that something could be done.
The point is, why try to use an inferior technological mechanism like
FTN when UUCP is available? Trying to bend the former into something
useful seems like a heavy lift.
I spoke to this above.
For that matter, why not try to do something like IP over RF instead?
RF has some advantages.
I think that IP has some disadvantages from an addressing & coordination >point of view. Both on directly attached links and at a larger routed >network scale.
IP tends to imply that you're wanting to do things across multiple hopes
in the network. That end-to-end connectivity is an Achilles Heal to me, >particularly in occupied / war zones.
Conversely UUCP's store and forward networking model avoids the
dependency on end-to-end connectivity.
I believe that IP simply adds additional layers of complexity that
aren't needed for two directly connected nodes to exchange files. I
think that UUCP is better equipped to do this.
Or even short messages sent over AX.25. Given that we know that
B-team Russian troops are using cheap consumer HTs on the 2m ham band,
one could conceivably put together a digipeater with a similar rig
and a Rasperry Pi with a battery in an ammo box unattended on a hill
somewhere: it is unlikely to be jammed. A network of those could
easily make it into Poland where an igate could pick short messages
and redirect them to anywhere; even twitter.
Yes. This type of thing is in the spirit of a notebook computer moving
from location to location.
Though I would question digipeating as I think that it verges on
multi-hop dependency.
Conversely, packet between two adjacent systems and exchanging files
with software to re-distribute them seems like it would be better IMHO.
A VPS somewhere that people could log into that's running a real
operating system (Unix or the like) would be more useful, IMHO.
The VPS tends to be a SPOF in a fixed and determinable location. It's
also a fixed identifier name / IP that will be easier to block.
As I mentioned above, to use a BBS for that, you need BBS software that
does it, which isn't super common. On the other hand, today one could
throw together a cheap Linux install on a Raspberry Pi with UUCP, GPG,
and mutt and make it work with as it would take to configure a BBS.
Aside: I think there is some room for quibbling over what is a BBS? ;-)
Some of the contemporary BBSs are exactly what you describe.
Similarly, what is a notebook other than a small portable computer?
What differentiates a notebook from a Raspberry Pi from a Pine64, etc?
All of which can probably do the same job equally well. (Save for the >different power needs.)
That's the hardest part in a combat zone.
Hard != impossible
I'm also expecting that the area with /active/ fighting is
proportionally small compared to a geographic area that has had / is
having / will have fighting take place in it. Obviously avoid the areas >where the /active/ fighting is.
Give me text every time; trying to follow instructions on a video
is a total PITA. I fear that's another battle already lost, though.
gtaylor@, please stop beating this dead horse. It becomes painful
(horse doesn't mind, it's already dead).
On 2022-03-12, Sn!pe <snipeco.2@gmail.com> wrote:
Give me text every time; trying to follow instructions on a video
is a total PITA. I fear that's another battle already lost, though.
Yet another unrealistic lamentation about textual preferences. Humans
prefer lower effort things. Experts or motivated amateurs who spend
many hours of their lives learning things, like reading and
transmitting text or code, become good at those things. News at 11.
UUCP as a dialup transmission mechanism does more than that but,
yes, if one were to try some kind of ersatz samizdat network
over dialup telephony, UUCP would be the way to go.
Related to this, I see that the most recent Firefox release has
been put out solely for the purpose of removing Yandex and Mail.ru
search functions and removing all customisations in their
"browsers".
"Yandex and Mail.ru have been removed as optional search providers
in the drop-down search menu in Firefox.
If you previously installed a customized version of Firefox with
Yandex or Mail.ru, offered through partner distribution channels,
this release removes those customizations, including add-ons and
default bookmarks. Where applicable, your browser will revert back
to default settings, as offered by Mozilla. All other releases of
Firefox remain unaffected by the change."
https://www.mozilla.org/en-US/firefox//notes/
Politics aside, I don't like one bit the way an open source
software project is willing to decide what services their users
should be using, and sabotaging 3rd party customisations.
I wouldn't want Putin deciding what websites I view, but I don't
want the software I use restricting my access to services that its
authors don't like either!
So in protest I'll point out that there is an "Add custom search
engine" add-on, which I used to replace the dead about:config
setting where I used to have the default search engine URL set to
DuckDuckGo Lite with my preferred parameters, before Mozilla
decided that was allowing their users too much freedom: https://addons.mozilla.org/en-US/firefox/addon/add-custom-search-engine/
On 15 Mar 2022 07:34:49 +1000
not@telling.you.invalid (Computer Nerd Kev) wrote:
"Yandex and Mail.ru have been removed as optional search providers
in the drop-down search menu in Firefox.
If you previously installed a customized version of Firefox with
Yandex or Mail.ru, offered through partner distribution channels,
this release removes those customizations, including add-ons and
default bookmarks. Where applicable, your browser will revert back
to default settings, as offered by Mozilla. All other releases of
Firefox remain unaffected by the change."
https://www.mozilla.org/en-US/firefox//notes/
With a quick browse around the site , I don't see a rationale either. Is there any possibility that there is legal justification due to sanctions against Russia ?
Politics aside, I don't like one bit the way an open source
software project is willing to decide what services their users
should be using, and sabotaging 3rd party customisations.
But it's not "politics aside" ; as far as I can tell , this is a political decision.
Yes indeed, I just meant that I didn't want my post to be
interpreted as an arbitrary defence of Russia rather than a
criticism of Mozilla's policy. I don't want Mozilla making decisions
on what services I use regardless of which political (ethical, etc.)
side they choose to take.
a) the zeitgeist of the 80s encouraged technological cooperation.
b) everybody's identity was public and most of them were academics
who valued their prestige.
c) barriers of entry (in terms of economical cost and the requirement
of technical knowledge of hardware and software).
In the case of an underground samizdat network in the 2020s (a) and (b)
would no longer apply, and the only protection against abuse and
flooding with low quality content is (c).
For the purpose of setting barriers of entry (c) packet radio would be
an ideal choice.
You two are avoiding one significant point of the puzzle. UUCP is fine
to move articles and files around. It doesn't handle subscription.
I couldn't find a search "add-on" available for web searching with
Yandex either, besides some little-used ones for image searching, so I
don't think it's just been removed as a default option, but as an
option altogether.
The problem I foresee with underground samizdat networks is how prone
they are to
1) abuse
2) flooding with low quality content
To some extent you can prevent abuse with things like GPG signatures.
But more than a technical problem, it is a social one.
the only protection against abuse and flooding with low quality
content is (c).
For the purpose of setting barriers of entry (c) packet radio would be
an ideal choice.
Good. Then could we please stop discussing the suitability of FTN
for this kind of thing?
IP is literally a store and forward networking protocol, though
it could be configured to communicate only with directly
connected hosts (ie, with no routing).
But it strikes me that the most useful thing is to talk to the
outside world.
What would this hypothetical network be used for, otherwise?
So does UUCP/FTN/whatever else. For that matter, so does the PSTN.
Those cell towers and copper pairs connect to something.
One generally needs digipeating for coverage, even in a geographically isolated area.
AX.25 mailers can already do this.
So is a telephone exchange, which you have been arguing for pretty strenuously. This argument is not self-consistent with your earlier arguments.
Besides, with IP connectivity, one could start to do things like have
that VPS accessible via a VPN, or TOR, or....
I'd love to hear examples of such BBSes that participate in FTN
networks.
...are you referring to my digipeater thing here?
The Raspberry Pi would be preferable due to (presumably) power power
draw than a notebook, and smaller form factor. The HCI hardware on
a notebook tends to imply interactive use; something you probably
don't want for a digipeater or whatever.
This are all false assumptions. I've been in a combat zone. What you
are proposing is, simply, unrealistic.
Given the conditions of the 2020s, I think it's best to assume that
all traffic should be encrypted/authenticated and to reject traffic
from unknown sources.
Zero Trust models are gaining prominence even in fat, fairly private
IP networks. In a samizdat environment with even semi-modern computing
power encryption should be simple to add on top.
For those unfamiliar, there's the
[NNCP](http://www.nncpgo.org/index.html) project which is spiritually
similar to UUCP but layers on encryption from the beginning. Peering
must be negotiated and keys exchanged out of band, but could have
promise on a Samizdat network.
I do think the realities of armed conflict are such that samizdat
network operators will probably stay in certain areas and transmit
on bands/connects that are hard to detect, while folks on the ground
will do their thing and probably interact in very simple ways (either
through simple physical word-of-mouth or by sending written messages,
or by setting up fixed rendezvous points to send/receive samizdat
messages.)
I think that NNCP is interesting. I do think that there is a
possibility for UUCP to be relatively easily extended to support for GPG relatively easily.
In comp.misc, Computer Nerd Kev <not@telling.you.invalid> wrote:
I couldn't find a search "add-on" available for web searching with
Yandex either, besides some little-used ones for image searching, so I
don't think it's just been removed as a default option, but as an
option altogether.
Does Yandex have the opensearchdescription code in the page? If so, can
you add it back using this old stardard method?
https://www.ghacks.net/2016/11/10/how-to-add-custom-search-engines-to-your-web-browser/
Checking, it seems yes, that would work. I see the green plus on my
fairly recent Firefox for yandex.com.
Yes from my understanding, this should be fairly trivial with UUCP
as well. You can always pipe UUCP payloads to a verifier which drops unverified payloads.
gtaylor@, please stop beating this dead horse. It becomes painful
(horse doesn't mind, it's already dead).
I was too young during the BBS days to use a BBS, but I generally hold
the opinion that those who are ignorant of history are doomed to
repeat it. I think documenting FTN would be a good exercise if
anything to help ambitious folks not recreate some of its foibiles in
modern IP networks.
On 3/14/22 8:24 AM, Dan Cross wrote:
Good. Then could we please stop discussing the suitability of FTN
for this kind of thing?
Okay.
IP is literally a store and forward networking protocol, though
it could be configured to communicate only with directly
connected hosts (ie, with no routing).
IP is not a store and forward networking protocol.
There is no persistent storage for IP.
Buffers, which /may/ be used for a very
short period of time are transient at best.
IP functions as a transport mechanism between two endpoints that may or
may not be directly connected to each other. The nature of how IP works >requires that all of the necessary routing segments be online and
operational between two IP endpoints /at/ /the/ /same/ time.
Conversely UUCP can easily exchange files without there ever being
end-to-end connectivity at the same time. UUCP only requires that each
pair of nodes be able to communicate and exchange files. A & B can
exchange files while B can't talk to C. B & C can exchange files while
B can't talk to A. A & C never have the ability to perform end-to-end >communications. This works perfectly fine with UUCP. IP will never
suffice without something (like UUCP / FTN / MQueue / ftp / etc.) on top
of it to exchange files.
B in this example could be a notebook / files on a flash drive / cd-rom
/ etc that is physically transported between A's location and C's location.
[snip]
What would this hypothetical network be used for, otherwise?
non-real-time communications; email, file transfer, etc.
Technically you could request web pages through it. Though the latency
would be ... painful. This would work through multiple out and back
cycles and / or out, package, and back cycle where the packaging deduces
the necessary supporting files (image, CSS, etc.) in support of the
requested file / page.
So does UUCP/FTN/whatever else. For that matter, so does the PSTN.
Those cell towers and copper pairs connect to something.
The crux is that IP needs all the elements of the path to be up at the
same time for end-to-end communications. Conversely UUCP only needs the
path elements between adjacent nodes. (See the A - B - C example above.)
One generally needs digipeating for coverage, even in a geographically
isolated area.
Maybe. Probably.
What if instead of digipeating the repeater node actually received the
files a la. UUCP, stored them, and then forwarded them on to the next
node. You end up breaking the A - B - C /multi-hop/ communications path
into two /single-hop/ communications paths that don't need to be
available at the same time.
This single vs multi hop becomes more of an issue as you integrate more
hops.
AX.25 mailers can already do this.
Fair enough.
Substitute AX.25 in place of UUCP. Well save for the fact that AX.25 >equipment is more specialized than UUCP equipment.
So is a telephone exchange, which you have been arguing for pretty
strenuously. This argument is not self-consistent with your earlier
arguments.
It depends on the scope of view and if things are mobile or not. The
town that I'm from had three separate telephone exchanges. If any one
of them became unavailable, it was not impossible to travel across town
to another location serviced by a separate telephone exchange.
If you want to consider the telephone exchange to be a link in A - B - C
and expand it as such A - (eA)(eB) - B - (eB)(eC) - C.
If A & B are on the same exchange and the exchange itself is down, then
they are going to have a hard time using the phone to connect to each
other. Fortunately there are other ways to get UUCP to communicate.
If A & B are on different exchanges, then perhaps the one on a dead
exchange can move to a different exchange and be able to communicate
with the other.
Aside: Fortunately UUCP is not dependent on the source {address,phone >number, port} /by/ /default/. As such, if A or B can move to other >exchanges, they can quite likely connect and exchange files.
Further aside: digipeating will have similar dependencies in that you
will be reliant on A's transceiver, both of B's transceivers, and C's >transceiver all (four) being operational at the same time. Things only
get worse as you add more hops.
Besides, with IP connectivity, one could start to do things like have
that VPS accessible via a VPN, or TOR, or....
IP introduces more complexity and more vulnerability.
I'd love to hear examples of such BBSes that participate in FTN
networks.
I believe the contemporary Synchronet and / or Citadel are effectively >standard Unix / Linux packages that may gateway to FTN. I feel like
there's another another major package that's effectively an FTN counter
part to uucico, but I can't think of the name at the moment.
I find ftnapps/FTNd / ftncico on GitHub, but that's not what I'm trying
to remember.
...are you referring to my digipeater thing here?
Not specifically a digipeater per se. Just any small computer being
used for whatever small computers are used for. Either system B being >physically carried between A and C in the example above, or the node >connected to the B transceiver to receive, store, and forward files via
UUCP, or anything else you want.
Similarly, what is a notebook other than a small portable computer?
What differentiates a notebook from a Raspberry Pi from a Pine64, etc?
All of which can probably do the same job equally well. (Save for the >different power needs.)
The Raspberry Pi would be preferable due to (presumably) power power
draw than a notebook, and smaller form factor. The HCI hardware on
a notebook tends to imply interactive use; something you probably
don't want for a digipeater or whatever.
Agreed.
This are all false assumptions. I've been in a combat zone. What you
are proposing is, simply, unrealistic.
So ... is every single square kM of Ukraine under /active/ fighting /
bullets flying?
My understanding is that there are hot spots / conflict zones in Ukraine
as Russian troops move in. Thus the obvious battle fronts are a
non-starter for anything tech wise. But I suspect that the areas on the >other side of Ukraine and behind the Russian front are both considerably >safer to move about than the active battle lines.
Is any of that /easy/? Absolutely not. Is it impossible? I doubt it.
Could sufficiently motivated people move about around outside of the
active combat zone? I suspect so.
This is simply incorrect.
First, whether or not there is "persistent storage" for IP datagrams transiting a network is an implementation detail.
Second, there is no persistent storage requirement for some network
to be based on store-and-forward techniques.
Store-and-forward simply means that a logical "packet" of data is
completely received via some intermediate node in the network before
being forwarded to the next hop en route to the eventual destination.
That's not true at all, either in theory or in practice.
Segments go down all the time, and datagrams may be routed across
any number of paths between two nodes.
Further, the network may be completely partitioned for some period of
time;
IP could care less.
If a path between nodes is re-established before some higher-level
protocol times out, it doesn't matter.
TCP connections have been known to remain in the "established" state
for _days_ in the face of a partition.
You seem to be conflating two related, but separate, things: the
physical transport used in some network, and the protocols that use
that transport. Here, one could usefully compare UUCP with SMTP
and HTTP or something similar, and IP versus a data stream over a
telephone line via e.g. a modem.
Perhaps I naively assumed it was obvious from context, but the whole
point of providing IP connectivity in this sort of scenario would be
to support higher-level protocols like those mentioned above.
You misunderstand me. What would be the point of this network?
If I may be blunt, you're fixating on specific technologies and
their hypothetical potential to "communicate" without considering
why people might want to use them or how they'd like to communicate.
That's not terribly useful.
See above.
This seems very confused.
With modem-based communications of any kind, you need the receiving
end to actually answer the phone. Since telephony systems are circuit-switched, that means that both ends and all intermediate steps
within the phone system have to be online in order to establish a
connection to exchange data. That those systems can then independently exchange data with other systems is irrelevant.
Incidentally, this is also how AX.25 mailers pretty much already work.
Here, you're simply avoiding the reliance on exiting infrastructure.
A $35 HT you can buy on Amazon and a rasperry pi is hardly
"specialized". The software is trivial to install on the Linux
distribution of your choice. In contrast, good luck finding a modem
if you want to use a landline, and one hopes those burner phones have
modems built in.
Unless you get shot at doing so.
...such as?
...and now you're back to this discovery issue. Phone numbers are
tied to exchanges. If you wish to send data to B, and the exchange
that B is connected to goes down, then B's number must change.
How does A know what the new number is?
What you are ignoring here is that radio is inherently a broadcast
medium.
As such, any station that can hear A can repeat to C.
As a technical aside, in the case of digipeating,I get the impression that we aren't using the same definition for "digipeating".
since AX.25 is based on packet switching, which is store-and-forward,
B only needs one transceiver.
You'll have to back that up with specifics.
Yes, but the context (which was removed) is that these do not do GPG.
I did not understand (and still do not understand) your point here.
Why would I want to use a notebook for a digipeater if I had something
like a Raspberry Pi to hand?
Those that are not can just continue what they've been doing and
use the Internet, so for those, this is all a moot point. I thought
we were talking about, effectively, clandestine networks for direct
combat zones and occupied areas.
I imagine that trying to "move around" as you describe behind Russian
lines is actually quite difficult. Getting caught with a burner phone
and a notebook running weird stuff is a good way to get detained and,
given that this is the Russian army we're talking about, very likely
shot once the counter intel people are done with you.
On 3/16/22 9:03 AM, Dan Cross wrote:
This is simply incorrect.
Please name one implementation of the IP protocol (v4 or v6) that will
store a packet, for at least multiple days, waiting for the next router
or endpoint to be serviceable again.
I'm explicitly talking about the IP protocol, not something that runs on
top of it that will retry subsequent connections when the previous
connection fails.
First, whether or not there is "persistent storage" for IP datagrams
transiting a network is an implementation detail.
It is extremely germane detail.
How is an IP system going to hold a packet for 14 days waiting on the
next router or remote system becomes available? Especially without >persistent storage and / or system reboots.
What you are suggesting is that an IP router (B) will hold an IP packet
from a different system (A) on it's way to yet another different system (C).
Second, there is no persistent storage requirement for some network
to be based on store-and-forward techniques.
Store-and-forward simply means that a logical "packet" of data is
completely received via some intermediate node in the network before
being forwarded to the next hop en route to the eventual destination.
How is a router going to store an IP packet for one or more weeks?
That's not true at all, either in theory or in practice.
I disagree.
[deleted a bunch of hypotheticals based on false assumptions]
Note how A and E have zero hope of ever establishing an IP connection
[deleted more incorrect stuff]
If a path between nodes is re-established before some higher-level
protocol times out, it doesn't matter.
That is a really big if.
[deleted more incorrect stuff]
You seem to be conflating two related, but separate, things: the
physical transport used in some network, and the protocols that use
that transport. Here, one could usefully compare UUCP with SMTP
and HTTP or something similar, and IP versus a data stream over a
telephone line via e.g. a modem.
I don't think so.
SMTP and HTTP rely on underlying protocols, namely IP.
UUCP provides it's own protocol and does not rely on any underlying >protocols.
Since both SMTP+IP and UUCP will require some physical link between
systems A & B, I'm ignoring the particulars about it for the moment.
[snip]
Re-using my example, are you meaning that B, C, D, and E are SMTP / HTTP >clients & servers too? Thus meaning that B, C, and D are actually not >functioning as IP routers?
You misunderstand me. What would be the point of this network?
To exchange information.
If I may be blunt, you're fixating on specific technologies and
their hypothetical potential to "communicate" without considering
why people might want to use them or how they'd like to communicate.
That's not terribly useful.
No, I'm not fixated on specific technologies. I'm fixated on specific >features / capabilities. I have gravitated towards specific
technologies that provide said features / capabilities.
The ability to exchange messages is the fundamental goal. I believe
that doing so is quite useful.
See above.
Indeed, see above. How are A and E going to communicate when there is
no alternate path and the path between them always has at least one
segment down.
This seems very confused.
I hope what I've outlined above with A, B, C, D, and E helps explain.
With modem-based communications of any kind, you need the receiving
end to actually answer the phone. Since telephony systems are
circuit-switched, that means that both ends and all intermediate steps
within the phone system have to be online in order to establish a
connection to exchange data. That those systems can then independently
exchange data with other systems is irrelevant.
Incidentally, this is also how AX.25 mailers pretty much already work.
Here, you're simply avoiding the reliance on exiting infrastructure.
AX.25, as I understand it, would probably be a good comparison to what
I'm describing with UUCP.
The down side is that (historically) far fewer people had access to
equipment necessary for AX.25 than did for UUCP.
A $35 HT you can buy on Amazon and a rasperry pi is hardly
"specialized". The software is trivial to install on the Linux
distribution of your choice. In contrast, good luck finding a modem
if you want to use a landline, and one hopes those burner phones have
modems built in.
Perhaps you touch on a point that relates to my (historically) comment
above.
Yes, an inexpensive HT and a mobile computer may be easier to order open >market /today/. However I suspect that ordering something open market
is antithetical to the environment that we're talking about.
I still think that it's far more likely to find more modems in the >environment that we're talking about than it is HTs.
But as stated above, AX.25 and UUCP are mostly interchangeable in this >scenario. If anything, chances are good that the inexpensive HTs that
you're describing are going to be 2m / 440 or other relatively short
distance communications, maybe across town. As such, you are going to
be dependent one or more intermediate nodes.
Unless you get shot at doing so.
I consider the possibility of getting shot at to mean that you are too
close to the active fighting.
...such as?
AX.25, null modem / IrDA if physically close enough, LoRA, sneaker net.
...and now you're back to this discovery issue. Phone numbers are
tied to exchanges. If you wish to send data to B, and the exchange
that B is connected to goes down, then B's number must change.
Sure.
There are all sorts of covert communications. I leave that to your >imagination.
How does A know what the new number is?
Thankfully, do to how UUCP operates, A doesn't /need/ to know B's new
number to communicate. B can call A, authenticate, and exchange
information just as if A had called B.
Part of what's exchanged can be
a message from B's operator to A's operator saying "I'm now at phone
number ...".
What you are ignoring here is that radio is inherently a broadcast
medium.
No, I'm not ignoring that.
As such, any station that can hear A can repeat to C.
No, that is not the case.
[Z]))) ((([A]))) ((([B]))) ((([C]
Z can hear A's broadcast, but Z can't repeat to C.
RF broadcasts are mostly nice, but they do have some side effects.
Besides the obvious of giving away your position, they also have the
problem of distance and geography.
In my state, there are many mountain valleys where the linear / daisy
chain scenario that I'm describing is quite common. Even adjacent
valleys tend to have to follow the daisy chain to a common point.
Cross valley communications at peaks is problematic for a number of >geographical reasons. Either it's difficult to clime the thousand(s) of >feet, or it's a sensitive point of failure / attack.
The point being that it is realistic to have the daisy chained
communications path.
As a technical aside, in the case of digipeating,I get the impression that we aren't using the same definition for >"digipeating".
To me, "digipeating" is a digital mode where two (digital) stations (A &
C) are communicating with each other through the repeater (B). Wherein
the repeater is receiving traffic from one station (A) and repeating it
to the other station (C) in real time as if the output of B's A side >transceiver is connected to the input of B's C side transceiver. --
This is an end-to-end network which requires that A, B, and C all be
online and operating at the same time.
Conversely, UUCP, or AX.25, one station (A) sends to the intermediate
system (B), independent of the operational state of the other station
(C). Subsequently, the intermediate system (B) sends to the destination >system (C), independent of the operational state of the other station
(A). -- This is a store-and-forward network which only requires
directly communicating systems to be operational at the same time.
since AX.25 is based on packet switching, which is store-and-forward,
B only needs one transceiver.
Yes! Hence the beauty of store-and-forward communications.
You'll have to back that up with specifics.
Not the least of which is addressing complexities.
Dependency on end-to-end IP connectivity.
VPN encryption key distribution is probably exponentially more complex
than addressing complexities. How do you make sure that the people that >/need/ the keys have them while ensuring that the people that shouldn't
have the keys don't?
Tor will compound things by introducing even more dependencies on
external entities. The bandwidth and latency issues with passing
through multiple independent Tor nodes ....
IP introduces more complexity and more vulnerability.
Yes, but the context (which was removed) is that these do not do GPG.
I question the veracity of the intention of your statement.
Technically, no, they don't have GPG as an integral part of their >functionality. However they can easily exchange (ASCII armored) GPG >encrypted messages.
The same can be said about UUCP, AX.25*, FTN, and even SMTP & HTTP(S).
AX.25 could be viewed as even more of a sticky wicket in that licenses
tend to prohibit encryption of any type. But if we're flaunting
licenses anyway....
I did not understand (and still do not understand) your point here.
Why would I want to use a notebook for a digipeater if I had something
like a Raspberry Pi to hand?
If you have a Raspberry Pi on hand and want to use it, then by all means
do so.
If you don't have a Raspberry Pi on hand and you do have an old
notebook, then I'd suggest using the old notebook verses doing without
the digipeater.
Similarly, what is a notebook other than a small portable computer?
What differentiates a notebook from a Raspberry Pi from a Pine64, etc?
All of which can probably do the same job equally well. (Save for the >different power needs.)
As I mentioned above, to use a BBS for that, you need BBS software that
does it, which isn't super common. On the other hand, today one could
throw together a cheap Linux install on a Raspberry Pi with UUCP, GPG,
and mutt and make it work with as it would take to configure a BBS.
Those that are not can just continue what they've been doing and
use the Internet, so for those, this is all a moot point. I thought
we were talking about, effectively, clandestine networks for direct
combat zones and occupied areas.
Depending on the amount of damage done in combat zones, there is a
chance that the traditional networks no longer function.
I imagine that trying to "move around" as you describe behind Russian
lines is actually quite difficult. Getting caught with a burner phone
and a notebook running weird stuff is a good way to get detained and,
given that this is the Russian army we're talking about, very likely
shot once the counter intel people are done with you.
That is a distinct possibility.
One of the nice things about UUCP is that you can carry files between >computers via sneaker net. Thus you don't have the burner phone or
computer. If people wanted to, they could put files on a micro SD card, >swallow it, travel, wait for the inevitable, read the files off on the
other end.
On 3/12/22 5:57 AM, Eric Pozharski wrote:
You two are avoiding one significant point of the puzzle. UUCP isPlease elaborate on what you mean by "subscriptions" in this context.
fine to move articles and files around. It doesn't handle
subscription.
I believe that something like news server exchanging things via UUCP
would provide /a/ subscription type model. What I'm not sure of is if
it would match what you mean by subscriptions in this context.
Let me be clear about what I've been saying in this thread, as
it appears to have been muddled:
* IP is a good protocol on which to base a clandestine
communications network in an occupied or active conflict
situation.
* The PSTN, and telephony in general, is not a viable
alternative to IP networks in this context.
* BBSes and FTN are poorly suited and best avoided.
* UUCP is acceptable, but has limitations related to the
underlying transport; this transport issue cannot be ignored.
* Packet radio using e.g. AX.25 or APRS is probably the simplest
and most robust mechanism for establishing a communications
channel. Noteably, one can use TCP/IP over AX.25.
* Unattended, cheap, throw-away digipeaters can be used to
extend range and coverage.
* In this sort of scenario, it is important to focus not so much
on the technology but on the use cases and environment. The
details, and getting them right, is critical to effective and
useful communications.
Indeed and now that I think about it, offering PPP over a link and
then sending your message to a mailserver over SMTP/IP is a very
simple thing to do in the hypothetical situation both of you have been discussing. That way you can still use your Raspberry Pi or laptop's
MUA to send mail and then have the MTA deal with the long-term storage
and forwarding.
That's irrelevant. You are factually incorrect about the
definition of a store-and-forward protocol.
IP is not connection-oriented.
This happens all the time, every day. It's one of the
foundational design principles of the Internet.
This is trivially incorrect. UUCP relies on some kind of
transport: either TCP/IP if transiting over the Internet, or
some kind of data stream provided by a modem or similar device
(or any number of other potential transports, but let's make it
easy on ourselves).
That data stream runs over something like an analog phone line.
How do you suppose those work, if not being based on
"underlying protocols"?
Those datagrams can be routed by a number of intermediate
routers along any available path between those two nodes. At
each such "hop", the datagram is read and buffered (stored),
examined for errors, and then (usually) forwarded towards the
intended destination by that router according to its internal
routing tables: this is what "store-and-forward" means.
Note that it has nothing inherently to do with persistent
storage.
Once the connection is established (standard SYN, SYN-ACK, ACK
"three-way handshake"), the higher-level protocol transfers
data in accordance with its semantics.
The implication is that the connection is resillient in
the face of intermediate failures while the connection is established,
given a sufficiently robust underlying networkd, and the endpoints are oblivious of intermediate failures while not actively exchanging data.
In the case of the Internet, we generally have a very robust
underlying network. In a conflict sort of scenario, the
challenge would be to provide that robust substrate. This can
be done by any number of means; for instance, one could even
layer IP on top of AX.25 (this is commonly done in the amateur
radio community), or use more robust protocols like ARNGLL (https://github.com/arngll/) over RF (note: we're still working
on ARNGLL).
Note that the establishment of the TCP connection is
conceptually similar to the establishment of a circuit in a
switched network, like the PSTN:
Yes, but you haven't articulated the parameters around which you
would like this to be used. The ability to communicate is
useful only insofar as the participants in the communication
actually have useful data to exchange. Two people coming up
with some elaborate protocol to drive to coffee shops and dial
up different phone numbers with netbook computers could just
talk on the phone, or meet in a park. Or do SLIP or PPP over
that dialup connection.
No sorry; if anything, that seemed to be based on some pretty
fundamental misunderstandings of the underlying technology.
The Russian army is literally running around with cheap HTs of
the kind I'm suggesting buying off of Amazon.
But you're advocating burner phones and notebooks using UUCP.
In the sort of environment we're talking about, where do you
suppose you're going to find those?
How, precisely, do you think that cell phones work?
Then what is this communications network you are proposing to be
used for?
Why not just throw WiFi in the loop and use TCP/IP and call it a
day?
Interestingly, these are all protocols that would also support
IP.
Furthermore, they're all protocols; something you said above was not
needed for UUCP because UUCP has its own protocols.
But that's the central technical challenge _you_ need to solve
if these hypotheticals you've been throwing around are to
actually be useful.
But the numbers are changing all the time.
Suppose A's number changed at the same time as B's.
Suppose B doesn't have access to an exchange at all. Suppose A isn't
in the coffee shop with the modem ready to answer when B tries to call. Suppose....
These are _all_ problems you _have_ to solve to realize any sort
of useful communications network.
You keep focusing on linear paths between stations and
constructing hypotheticals around that. Once you get over this
fixation on "paths", and you can start thinking about creating
other, more robust topologies.
You're taking a statement too literally. Perhaps I should have
written, "can potentially repeat to...". I naively assumed that
was clear from context.
Furthermore, unlike in wired networks, nothing prohibits the
introduction of a new node (call it "D") that may in range of
both Z and C.
I suppose now you will construct some scenario based on
geography that precludes such a configuration, which would be a
profound misreading of the point that RF-based networks can be
mesh-oriented and hence very flexible.
That's why I mentioned digipeating for coverage initially.
You mean like a telephone exchange? How would a telephony-based
approach be any less vulnerable in that sort of scenario?
As for being hard, well, war is hell man.
Sounds like a problem for every other potential comms plan as
well. This is why military communicators, emergency services,
and amateur radio operators plan for redundancy in their
topologies.
That's incorrect. A digipeater in an AX.25 context is a
store-and-forward thing; it reads a packet, buffers it, and then
retransmits it,
Digipeaters are often used in the same way that repeaters are in
e.g. FM phone communications; one uses them to boost range, not
necessarily to create complex network topologies.
There are also digipeaters already on amateur-radio carrying
satellites, and the ISS. And yes, they can be used with the
same cheap HTs I'm describing. So you don't even necessarily
need to set anything up yourself.
APRS can already gateway to twitter and SMS.
You're using AX.25 in the example you just used to argue against
AX.25.
It's somewhat odd that you seem to understand that AX.25 is a store-and-forward protocol, but assert that IP is not.
How is that any different than any other communications
protocol?
That's vague and unspecific, and "bandwidth" and "latency" are
obviously a problem if using low-bandwidth dialup connections.
Is the point to usefully communicate or surf the web?
I asked for specifics, but you did not provide them. Vague
hand-wavey answers just repeating the assertions do not count.
Any number of MUAs that can be used with UUCP/SMTP support GPG.
Extant BBS packages supporting FTN just don't. Why go with a
more complex solution with a simpler one, that fits the
application domain better anyway, already exists? Just because
you *can* do a thing doesn't mean that it's a good idea to *do
that thing*, and "BBSes" in the sense usually inferred when
discussing FTNs are a poor fit for this sort of thing.
In an emergency situation ... those restrictions basically go out
the window. Pretty much every licensing authority on the planet is
agreed on this point: if you're out hiking and grandpa has a stroke,
you the unlicensed kid can absolutely use that HT to call for help.
... like we are presently seeing in Ukraine ...
Similarly, if you are resisting a foreign invasion, I think the
relevant authorities will give you a pass after the fact for
using crypto on amateur frequencies.
How is that relevant to the above?
Which is why you probably don't want to base your solution on
relying on those.
You could just do that with a filesystem on the SD card. But
often in situations like this, the movement of people is
restricted outside of a geographical area, for precisely this
sort of thing. Muling SD cards through the digestive track may
sound all kinds of cool, but isn't really useful if you can't
get to some place where someone who can consume the data is,
anyway.
Let me be clear about what I've been saying in this thread, as
it appears to have been muddled:
* IP is a good protocol on which to base a clandestine
communications network in an occupied or active conflict
situation.
* The PSTN, and telephony in general, is not a viable
alternative to IP networks in this context.
* BBSes and FTN are poorly suited and best avoided.
* UUCP is acceptable, but has limitations related to the
underlying transport; this transport issue cannot be ignored.
* Packet radio using e.g. AX.25 or APRS is probably the simplest
and most robust mechanism for establishing a communications
channel. Noteably, one can use TCP/IP over AX.25.
* Unattended, cheap, throw-away digipeaters can be used to
extend range and coverage.
* In this sort of scenario, it is important to focus not so much
on the technology but on the use cases and environment. The
details, and getting them right, is critical to effective and
useful communications.
Constructing strawmen to prove a technical point isn't really
all that interesting to me.
Wanabe Sysop (aka a Point, aka FTN-Compatible Sysop) sends netmail to
their Boss (aka Sysop) with To set to special AreaFix nick (nicks are arbitrary, routing is concerned with addresses) with a line '%AVAIL'.
Then waits.
Meanwhile, AreaFix (at the Boss) sends '%AVAIL' requests to AreaFix'es
to all its peers. Then waits.
Eventually, replies from peers are somehow pressed into something
that roughly may be interpreted as a reply.
Then the Point receives more or less (mostly more) copious list
of echos.
Now comes most exciting part. The Point goes through couple of
thousands of malformed lines.
And they must be careful what they pick -- there are echos sources from different networks, regions, and zones (potential to cause fatal drama (potentianlly, international); such drama will be fatal to the Point,
because noone gives a fsck about points), unreachable (physically)
flea markets, and echos some bosses keep to deal with their points.
When desired echos are picked, then list is sent to the AreaFix again.
Then Point waits.
Now the Areafix sends subscription requests to its peers, and then
waits.
Then, eventually, a message comes through this creates echo locally
thus enabling the Point to achieve The Conversion Experience. However, sometimes initiating message never comes (like I can see FTN traffic
in Usenet, subscription succeeds (I can verify, I'm subscribed),
and nothing happens).
If you don't see experience, then I don't know what experience is.
Something alike is FileEcho's (different robot -- 'FileFix', and
somewhat different mechanics). However, I hadn't no ability then
reasons then chance to use it (for many different reasons), thus I
can't describe it myself.
Well, looking how this thread is developing I'll better abstain.
On 3/4/22 5:51 PM, meff wrote:
How does this affect Usenet?
It depends.
Have any prominent providers stopped allowing access from Russian
IPs or ASNs?
What do you consider "prominent providers" to be.
Cogent, a major backbone / connectivity provider is de-peering Russian clients. So there is a good chance that Internet connectivity between
parts of Russia and other parts of the world will be less reliable if
not out & out broken (if more providers follow suit).
Other big names in tech, particularly social media, are blocking Russian clients.
We are witnessing what may be the first steps of a significant fracture
of the Internet, and thus in many ways, Usenet. The coming days / weeks
will show ho significant the fracture will be.
On 3/17/22 8:50 AM, Dan Cross wrote:
That's irrelevant. You are factually incorrect about the
definition of a store-and-forward protocol.
Why don't you share the definition that you're using for store-and-forward.
I'm using the following definition for store-and-forward networking: Something receives a message from a sender, stores it for some (possibly indeterminate) amount of time, and then sends it to the next system in
the path at some point in the future.
Retrograde <fungus@amongus.com.invalid> wrote:
How do you know Usenet isn't accessible in Russia? Not doubting you,
just trying to figure out if it's true.
Usenet is hardly accessible at all anywhere. Used to be every ISP had
a fast local server, now basically everyone is on a handful of big servers and that kind of defeats the whole purpose.
--scott
Looks like we’re going back to the Kremvax days.
Let me be clear about what I've been saying in this thread, as
it appears to have been muddled:
* IP is a good protocol on which to base a clandestine
communications network in an occupied or active conflict
situation.
* The PSTN, and telephony in general, is not a viable
alternative to IP networks in this context.
* BBSes and FTN are poorly suited and best avoided.
* UUCP is acceptable, but has limitations related to the
underlying transport; this transport issue cannot be ignored.
* Packet radio using e.g. AX.25 or APRS is probably the simplest
and most robust mechanism for establishing a communications
channel. Noteably, one can use TCP/IP over AX.25.
* Unattended, cheap, throw-away digipeaters can be used to
extend range and coverage.
* In this sort of scenario, it is important to focus not so much
on the technology but on the use cases and environment. The
details, and getting them right, is critical to effective and
useful communications.
Indeed and now that I think about it, offering PPP over a link and
then sending your message to a mailserver over SMTP/IP is a very
simple thing to do in the hypothetical situation both of you have been >discussing. That way you can still use your Raspberry Pi or laptop's
MUA to send mail and then have the MTA deal with the long-term storage
and forwarding.
It appears that you two are talking past one another.
Dan is conflating store and forward packet switching with store
and forward networking and believing that both mean the same thing
and then arguing that IP is a store-and-forward system (without any qualifiers to indicate what subset he is referencing).
While some IP switches/routers can operate in a store-and-forward mode
(whole IP packet is first received into memory before the header is
analyzed to determine which link to transmit the IP packet, then the
packet is transmitted (or dropped) depending upon the header analysis)
this is not a requirement of IP networking. It is also possible, and
many very high performance switches/routers do, for the switch/router
to analyze the headers as they are received off the line, decide
where to send the packet, and begin transmitting the packet on the
outbound link while the remainder of it is still being received on
the inbound link.
Dan has conflated an invisible (to IP) implementation detail of
router/switch hardware with a requirement of the protocol itself
(as in SMTP protocol which explicitly requires that it operate in a
store and forward networking mode) and is therefore arguing that IP is
"store and forward". But IP does not require switches/routers operate
in store and forward mode. Whether they do, or not, is invisible to,
and unspecified by, IP.
And even those routers/switches that /do/ operate in a store and
forward like mode for IP, they do not 'store' said packet any longer
than necessary to make their routing decision.
If their header analysis indicates they do not know where to forward
the packet, they drop it and move along.
This is the critical distinction that Dan appears unaware of that differentates packet store and forward systems from what the rest
of us term store and forward networking (i.e., SMTP like store and
forward operation).
On 3/17/22 8:50 AM, Dan Cross wrote:
That's irrelevant. You are factually incorrect about the
definition of a store-and-forward protocol.
Why don't you share the definition that you're using for store-and-forward.
I'm using the following definition for store-and-forward networking: >Something receives a message from a sender, stores it for some (possibly >indeterminate) amount of time, and then sends it to the next system in
the path at some point in the future.
IP is not connection-oriented.
Pick any higher transport layer protocol that want and it will still
fail to establish communications when there is not an end to end path
for IP to take.
On 2022-03-04, Oregonian Haruspex <no_email@invalid.invalid> wrote:
Looks like we’re going back to the Kremvax days.
I2pd it's an interesting alternative to avoid that.
They have several Russian servers on the IRC proxied
servers (two), but one of the two it's almost Russian
language based.
They have an NNTP server, too. Setting up i2pd is not
dark magic, I can write a guide if anyone wants.
On 3/12/22 8:47 AM, Dan Cross wrote:
Sadly, that doesn't make it any less true.
Please elaborate on why the Internet is required when a group of people
make dial up connections to each other using FTN and / or UUCP.
UUCPNET in the 80s was a cooperative network of universities and
companies and all admins on it were well behaved and cooperated.
Everything was unencrypted, and yet nobody was spoofing emails,
nor doing crapflooding. I guess that the reasons for cooperation were
a) the zeitgeist of the 80s encouraged technological cooperation.
b) everybody's identity was public and most of them were academics
who valued their prestige.
c) barriers of entry (in terms of economical cost and the requirement
of technical knowledge of hardware and software).
Dan is conflating store and forward packet switching with store and
forward networking and believing that both mean the same thing and then >arguing that IP is a store-and-forward system (without any qualifiers
to indicate what subset he is referencing).
I was too young during the BBS days to use a BBS, but I generally hold
the opinion that those who are ignorant of history are doomed to
repeat it. I think documenting FTN would be a good exercise if
anything to help ambitious folks not recreate some of its foibiles in
modern IP networks.
On 2022-03-18, bozo@dev.null <bozo@dev.null> wrote:
On 2022-03-04, Oregonian Haruspex <no_email@invalid.invalid> wrote:
Looks like we’re going back to the Kremvax days.
I2pd it's an interesting alternative to avoid that.
They have several Russian servers on the IRC proxied
servers (two), but one of the two it's almost Russian
language based.
They have an NNTP server, too. Setting up i2pd is not
dark magic, I can write a guide if anyone wants.
I'm curious if you have thoughts on why I2P instead of Tor, or
vice-versa (or neither). Just safer to not have to deal with the
concept of an exit node?
Few things are as well documented as the FTN. There are miles upon miles
of Bell operating manuals.
--scott
On 3/17/22 11:11 AM, Eric Pozharski wrote:
Wanabe Sysop (aka a Point, aka FTN-Compatible Sysop) sends netmail toOkay. It sounds like '%AVAIL' propagates out multiple degrees; 1st
their Boss (aka Sysop) with To set to special AreaFix nick (nicks are
arbitrary, routing is concerned with addresses) with a line '%AVAIL'.
Then waits.
Meanwhile, AreaFix (at the Boss) sends '%AVAIL' requests to
AreaFix'es to all its peers. Then waits.
point to node; 2nd node to nodes.
How many degrees out does the '%AVAIL' go? Is there a limit? Or is
it until it floods to all nodes in the FTN in question?
And they must be careful what they pick -- there are echos sourcesI can see how a point has a potential to cause ... problems by
from different networks, regions, and zones (potential to cause fatal
drama (potentianlly, international); such drama will be fatal to the
Point, because noone gives a fsck about points), unreachable
(physically) flea markets, and echos some bosses keep to deal with
their points.
requesting something that disrupts the network.
Well, looking how this thread is developing I'll better abstain.It seems to me like AreaFix / FileFix automate the process of what I
consider to be newsgroup subscription management. What's more is that
it seems like an off system (point) can initiate an automated change
on a parent (point's upstream node) and maybe even remotes (parent's
peer node(s)).
I'm not aware of any automated subscription management on news servers
/ Usenet. In news servers / Usenet, this amounts to an email to the
peer news master(s) asking them to alter the feed.
On 3/17/22 8:50 AM, Dan Cross wrote:
That's irrelevant. You are factually incorrect about the
definition of a store-and-forward protocol.
Why don't you share the definition that you're using for store-and-forward. >>
I'm using the following definition for store-and-forward networking:
Something receives a message from a sender, stores it for some (possibly
indeterminate) amount of time, and then sends it to the next system in
the path at some point in the future.
It appears that you two are talking past one another.
Dan is conflating store and forward packet switching with store and
forward networking and believing that both mean the same thing and then >arguing that IP is a store-and-forward system (without any qualifiers
to indicate what subset he is referencing).
While some IP switches/routers can operate in a store-and-forward mode
(whole IP packet is first received into memory before the header is
analyzed to determine which link to transmit the IP packet, then the
packet is transmitted (or dropped) depending upon the header analysis)
this is not a requirement of IP networking.
It is also possible, and
many very high performance switches/routers do, for the switch/router
to analyze the headers as they are received off the line, decide where
to send the packet, and begin transmitting the packet on the outbound
link while the remainder of it is still being received on the inbound
link.
Dan has conflated an invisible (to IP) implementation detail of
router/switch hardware with a requirement of the protocol itself (as in
SMTP protocol which explicitly requires that it operate in a store and >forward networking mode) and is therefore arguing that IP is "store and >forward". But IP does not require switches/routers operate in store
and forward mode. Whether they do, or not, is invisible to, and
unspecified by, IP.
And even those routers/switches that /do/ operate in a store and
forward like mode for IP, they do not 'store' said packet any longer
than necessary to make their routing decision. If their header
analysis indicates they do not know where to forward the packet, they
drop it and move along. This is the critical distinction that Dan
appears unaware of that differentates packet store and forward systems
from what the rest of us term store and forward networking (i.e., SMTP
like store and forward operation).
Few things are as well documented as the FTN. There are miles upon miles
of Bell operating manuals.
Bell Operating Manuals?
Because much of the FTN and pretty much all of UUCP is now carried over IP.
All of that legacy physical infrastructure is long gone. It looks like it's there from up top because the functionality remains, but when you look under the hood you will find that functionality is provided by IP now.
Bell Operating Manuals?
Yes, and rooms and rooms full of Bell System Practices manuals.
--scott
On 2022-03-21, Scott Dorsey <kludge@panix.com> wrote:
Bell Operating Manuals?
Yes, and rooms and rooms full of Bell System Practices manuals.
Are they available on the net anywhere?
Scott Dorsey wrote:
Bell Operating Manuals?
Yes, and rooms and rooms full of Bell System Practices manuals.
Are they available on the net anywhere?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 388 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 05:59:10 |
| Calls: | 8,220 |
| Calls today: | 18 |
| Files: | 13,122 |
| Messages: | 5,872,261 |
| Posted today: | 1 |