Grant,

> Seeing as how you are wanting to do something akin to a proxy for TCP
> traffic, I would suggest that you use a USB-to-Ethernet dongle for a 2nd
> Ethernet interface.

Thanks.  I already got that idea too, but as I know almost nothing about the
possibilities ...

> As others have stated, a Layer 2 managed switch using 802.1Q VLAN tags is
> a perfectly viable option too.
>
> Which you use will probably depend on what you have available and / or
> want to purchase.

Well, I'm most always going for a solution that is easiest to manage and has
the largest usage area - even when I almost certainly will never move the
thing.  IOW, when executed my choice will be the dongle.

>> No, no intermediate network.
>
> A routed network doesn't necessarily mean that there is something in
> between the networks.

As far as I can see B is in between the AB and BC networks ...

But yes, I was imagining a routing over yet another LAN segment.

> Do you want A and C to be able to establish TCP connections with each
> other?  E.g. through a router of some sort?

Nope, never.

> Or do you want A to *ONLY* be able to establish a TCP connection with B,
> and likewise with B & C?

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

> This may seem like a minutia difference.  But it is a very important
> difference.  If you're okay with A and C establishing a TCP connection
> with each other through an intermediate router (B), then much of this
> conversation is moot.  Like a mic drop.

:-) I'm quite aware of that.

> Now you're talking more about something between NAT and an ALG / Proxy.

Not quite.  As I said, the port information is dropped too.  Always.

> You don't even need Samba / NFS / etc. on the intermediate host B.

Indeed.

> A will /think/ that it's talking to B when in fact it's /really/ talking
> to C.  Likewise, C will /think/ that it's talking to B when in fact it's
> /really/ talking to A.  It's just that A and C will have a different idea
> of what each other's address is.

Yep.  But with a small twist: In my initial idea B was truly passive.
Receiving a connection from A would not provoke it to try to make a
connection to C.  It would do nothing until C also connected to it.  Only
than it would exchange datapackets.

Currently I'm cautiously sporting the idea that /maybe/ B could, when
receiving a connection from either side, open a connection to the other side
itself - on a fixed port ofcourse.

> No.  Not as such.  UUCP works by running a command on A that tells UUCP on
> A, B, and C, to transfer the file to C.

Ah, I misunderstood what it might do.

> Remember, even a file drop, can enable programs on A and C to communicate
> with each other.

Yes, I'm aware of that.    The whole idea is that I /want/ them to
communicate - but only on my conditions.

>> Agreed.  But I would not have any qualms to install SAMBA twice, once for
>> each interface, only coming together on the file-storage level.
>
> You only install Samba once.  You only need to run one instance of it.

I understood that.   It was just to make a point as to how far I would go to
keep everything apart.

>> maybe automatic clipboard exchange later.
>
> Now you're talking about something a LOT more involved.

Not really.   I wrote something like that a number of years ago. Text only
though.  That was all I needed it for.  And I never actually finished the
"automatic" part though. I would have needed a data-hash check to stop data
storms, but eventually dropped that idea.   Instead I simply used a "send"
button.  Served two purposes: No data storms, and being able to copy-paste
private data without automatically having it land on other 'puters.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05