On 6/29/20 1:43 PM, Dennis Lee Bieber wrote:
> Except, from your examples, the source is still requesting a route to
> the final destination -- which the OP seems insistent is not viable
> for him. He wants both sides to only address the R-Pi in the middle,
> and they must each initiate the connection /to/ the R-Pi.

I think we are in agreement.

Though I think we have different understandings of what's going on.

Both A and C initiate a connection to the R-Pi (B).  UUCP transfers the
files on our behalf.  It uses a directory structure with multiple
sub-directories as queues for the destination system.  Both A and C pull
files from B if there are any queued for them.

I think what is and is not acceptable to the OP is somewhat of a
quagmire and difficult to say with any degree of certainty.  I think
there are two things that the OP would like, and they are somewhat at
odds with each other, at least in how they achieve a common overarching
goal.

The only thing that I think UUCP falls short on is the fact that A and C
know that they are talking to the other and that it is by way of B.
But, based on my current understanding of the OP's desires, I don't
think this is really a /problem/ so much as it is a strong /desire/.

I honestly believe that UUCP does bring much in the form of a solution.
I wouldn't have suggested it if I didn't think so.

> Which, even with UUCP, comes down to the source connecting/passing
> the data to the R-Pi only, and the destination also using UUCP for
> connecting/fetching the data from the R-Pi. So... again we have the
> R-Pi as a file drop/mail box and UUCP/NFS/(s)FTP are essentially
> equivalent in functionality. Files are transferred into some storage
> on the R-Pi -- there is no real time packet transfer from one machine
> to the other (and especially no ad-hoc protocols).

One big leg up that UUCP has is that it is an established mechanism for
dealing with this, retrying, multiple systems, and does not require any
form of solutioning.  Others at the very least require defining and
managing a queue structure.  I also question how well things will deal
with the R-Pi (B) NAS being unavailable when they want to push new files
or poll for / pull queued files.

> What the OP wants is almost the reverse of a VPN where both sides are
> treated as part of the same local/private network, with connections
> tunneled through the unsecured public network to a VPN server.

Sort of.  But much more restrictive.  And without relying on a firewall
to impose that restriction.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05