On 6/26/20 3:15 AM, R.Wieser wrote:
> I think this is one of the few instances where a single "yes" is
> appropriate. :-)
>
> I have not ever, nor do I intend to have them ever communicate with each
> other over ethernet.

The motivation behind the current state is more important than what the
current state is.

> Nope and yes.    Thats why I placed them on their own subnets.

I thought such might be the case.  Now I know for sure.

> Nope.   I thought about that, but consider it to be too dangerous - unless I
> would only allow only a very small range of ports thru, with zero
> firewall-intelligence (opening other ports when the "inside" 'puter asks for
> it).  But that would mean I would need to be very sure that no port in the
> allowed range would be used by any of the 'puters default, or later
> installed programs/services.   As I can't be I decided that the "postoffice"
> way of handling stuff would be best.

ACK

> I have been considering hooking up two 'puters thru a classic RS232
> connection (DB9 connectors).  Alas, even on their highest speeds, 128000
> bps, it islaughably slow in comparision to a LAN connection.

What would you do with the serial connection that you wouldn't /
couldn't do with a direct Ethernet connection?

> I don't know anything about UUCP, and have to look into it.

In this context, UUCP is a way to get files between systems A and C, via
B, without A and C having the ability to communicate with each other
directly.

Push a file:

    A$  uucp /path/to/local/file B!C!/path/to/remote/file

Pull a file:

    A$  uucp B!C!/path/to/remote/file /path/to/local/file

Both of these commands cause the local system (A) to send a request /
file (respectively) to C via B.  B receives the request / file and sends
it to C.  In the pull example, C will send the requested file to A via
B.  B receives the file from C and sends it to A.

Each of these steps are asynchronous.  It's possible to configure UUCP
to connect-on-demand.  Meaning that as soon as the UUCP system on A has
a request / file, it will immediately connect to B.  Then once the UUCP
system on B has a request / file it will immediately connect to C.  ...
likewise going back the other way.

A and C do not have any ability to talk directly to each.  B must be in
the middle of the communications.

Another nice thing is that A and C can communicate via B even if the
other end is powered off.  A & B talk while C is powered off.  Then B &
C talk while A is powered off.  Then A & B talk (again) while C is
powered off.

You can send / pull files, email, news (e.g. Usenet), or even remote
commands if you choose to allow them.

All three machines have a modicum of control of what they will allow the
other system to request / do.

You can even send files to remote users without specifying where they
should go.  Conversely, you can collect files that were send to you in
the same manner.  This is nice for sending a file without worrying where
it's supposed to live on the remote end.  As if I wanted to send you an
mp3 file and have zero knowledge of where you want it saved.  Much like
an email attachment.

Feel free to follow up with questions, be it here, or email me directly.

> Though the programs are less of a problem.  I enjoy programming, and have no
> problem with trying my hand at writing stuff for both the (Windows) 'puters
> as well as the RPi (even though I'm a very much a novice on the latter).

I have run versions of UUCP on Windows that exchanged files with my
Linux systems without a problem.

Specifically, I had a radio tuner that would record a particular show
and save it as a wave file.  There was a batch file that was run (after
the show) as a Windows Scheduled Task that would convert the wave to an
mp3, then use uucp to ""send said mp3 to my server via an intermediate
system.  (The Windows system could only communicate on the LAN.)  The
intermediate system would then pass the file on to my web server.  My
web server would run a nightly script (via cron) that would pick the
file up, move it into place, set permissions, and update an RSS feed.
Thus I had two systems (A and C) which could not communicate with each
other (for security reasons) exchanging files via an intermediary (B)
without any problem.

The store and forward nature of UUCP made this extremely resilient.  A
could go about it's business of recording, converting, and sending
files, even if B was inaccessible (b/c A was disconnected from the
network).  Then once A could communicate with B again, any files that
had been queued up would be transferred.  Likewise with B and C.

> The biggest issue is if the RPi allows for electrically & programmatically
> seperated ethernet connections, and allows me adress the ethernet interfaces
> seperatily.

As others have pointed out, this is fairly easy to do.  I'll not add to
the quagmire that are the responses to that discussion, other than to
say that additional USB NICs and / or VLANs can work quite well when
configured properly with hardware that properly supports them.

> I'm not really considering (very) big files, but would like to be able to
> move a gig or so without having to wait for the better part of a day (as I
> would need to when using an RS232 connection).

I do not recall transferring files that were bigger than double digit MB
through UUCP.  But I expect that you could transfer multi-GB files as
long as the spool has sufficient room on all systems.

Seeing as how it's UUCP over TCP or SSH, it will move at relatively the
same speed as the wire; 10 Mbps, 100 Mbps, etc.  So you wouldn't be
waiting for serial speeds.

> P.s.
> I just realized I should take a peek at USB-to-RS232 converters.  Those
> might well have a much higher thruput than what the UART offers.

I doubt it.  Remember that USB-to-RS232 adapters are meant to be a
contemporary UART.  That being said, you could probably find
USB-to- that will be faster.  You might
even find that USB-Gadget mode can emulate a serial connection that will
run considerably faster than RS-232 and go directly between A & B and B & C.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05