Grant,

> Does that mean that you will terminate the TCP connections from A /on/ B
> and initiate a /new/ connection from B to C?  (And vice versa.)

No.   It means that when A connects to B than B will do /nothing/, other
than to wait until C connects to it   (and vise vera).

And yes, that means that /both/ connections terminate at B.

>> Yep, that.    And to be honest, I could not care less how it happens, as
>> long as they can exchange data without actually being able to connect set
>> up random connections to each other.
>
> Well, you do care.

:-) I ment that in the sense of whatever kind of (physical) connection was
used, regardles of it being ethernet, serial, "USB bridge" or other.

>> Hence my side-step in the direction of a serial connection.   Data can
>> flow, but without specially written software that data comes from nowhere
>> and goes to nowhere else than from/into my program.
>
> You say that.  But said specially written software has existed in the
> Linux kernel for 20+ years.

:-) Mind you, I'm attempting to connect two Windows 'puters.  But does Linux
automatically grab a serial connection and feed it into its OS ?   Or does
it allow me to chose if I want to handle the raw data myself ?    In the
latter case there is zero problem.

>> Not quite.  As I said, the port information is dropped too.  Always.
>
> The /old/ port information (A to B) may be dropped.  But there is /new/
> port information (B to C) created.

How is that a problem ?    How could that be used to break the isolation
between A and C ?

> B may not /initiate/ the connections.  But it will very much be an active
> participant in each of the connections.

I think your definition of "will very much be an active participant" is a
bit different from mine.    But why else do you think I would put it in
there ?   To play paperweight ?

> "on my conditions" implies some sort of /active/ decision making.  ;-)

Thats impossible.  All my decisions are of the passive kind !   Uninformed
and not even thinking about how that might be a bad idea, 'cause that would
be something active. :-p

> I still maintain that interfacing with the system clipboard on multiple
> systems is more complicated than a simple file drop.

I think you misunderstood.    I simply copied one the (text) contents of the
clipboard from one machine to the clipboard on another machine.  From there
the other machine could do with it whatever it wanted.   Another KISS style
solution. :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05