On Sun, 28 Jun 2020 22:22:31 +0200, "R.Wieser" 
declaimed the following:

>Dennis,
>
>> You still aren't clear on WHAT this communication IS...
>
>Ah.  The answer to that is simple: Anything I want.    Datapackets normally
>do not care what they contain. :-)
>
>And that is all I intended the connection with the RPi as a middle-man to
>be: To be able to send data either way, but without either of the two sides
>being able to see each other.   No more, no less.

 Data packets may not care what they contain, but the addressing is
crucial. Servers wait on KNOWN ports for clients (using random assigned
ports) to connect. Once connected, those servers expect the data packets to
contain data conforming to some defined protocol (sending an SMTP formatted
email message to a server on port 80 is not going to work -- port 80 is the
standard for HTTP formatted messages).

 This is where your "A connects to B", "C connects to B", and now data
flows falls apart. Especially if "A" connects to "B" twice (say two
different programs want to transfer different data to "C"). Both
connections are made to the single server port on "B". How does "C" make
two connections to "B" and /somehow/ identify WHICH connection from "A" it
means expects (or vice versa, if "C" makes to connections to "B", how does
"A" identify which one it wants to connect with).

 And again, since you are connecting to a single known port on "B" --
you need to provide clients on "A" and "C" that can then handle whatever
data is being passed between them.

 The only scheme that truly keeps "A" and "C" from knowing details about
each other is the file drop/mail box scheme, in which "A" connects to "B",
transfers a file into a mail box directory for "C" (it may know some name,
if you have multiple nodes on each side, as it needs to access the node
specific mail box/directory) and "C" connects to "B" to read the mail box
(and if needed drop files into the box for "A").

 Avoiding C reading before A finishes writing requires some upper level
convention -- such as using some special file extension during the write,
and after the write completes do a rename operation. The other side is not
supposed to read files with the special extension. OR -- you first write a
lockfile (contents don't matter, just that the name is the actual file +
some extension). If lockfile is seen, do not read file without the
extension. Both styles do have a problem -- if a process on the sending
side fails before the rename, or the lockfile deletion, one has dangling
files in the mailbox (a CRON job that checks, say, every three hours for
lockfiles that are 6 hours old or older could delete the lock [unless you
have transfers that take more than 6 hours] or just delete the file with
the special extension [presumes B can't know what the real file extension
is supposed to be].


--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05