On 6/28/20 9:58 PM, Dennis Lee Bieber wrote:
> 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).

I largely agree.

> 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.

Though it is hypothetically possible that some of the addressing can be
moved to inside the data.  Thus hypothetically it could be made to work.
  But it would be extremely atypical and custom.  There would also be
multiplexing issues.  Can they be overcome?  Probably.  Though I
question the practicality of doing so.

802.2's SSAP / DSAP (collectively known as LSAP) comes to mind.

> 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").

Yep.  This is some of what UUCP does.

> 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].

Another trick is to have the file, with a specific naming convention /
extension be the lock file.  Once the write is complete, rename or move
the file, so that it is ready to be found by a specific naming convention.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05