4 May
2018
4 May
'18
8:43 a.m.
On 2018-05-04 05:49, Robert Armstrong wrote:
Correct. My application have to decide whether to accept more than one
connection. And it can do that. But each accepted connection is it's own
TCP connection, and has its own circuit on the DECnet side.
It does not have to know DECnet node is on the other end. That's for
DECnet to figure out, which it does in the initial handshaking on any
circuit that comes up. There is actually nothing in my DECnet-over-IP
that defines anything at the DECnet level. I define the circuit. I do
not tell what DECnet address is at the other end of that circuit.
Do the VMS Multinet require that you define that kind of information?
It's TCP.
It's always point to point. There are no broadcast ability in
TCP. However, there is nothing preventing you to have multiple TCP
connections with the same local port. It's still separate connections.
Fair enough, but your application which listen() for connections has to decide whether
it will accept() more than one. If your MUltinet DECNet tunnel thingie only accepts one,
then by definition you can only have one connection per TCP/IP port. If it accepts more
than one, then how does it know which DECnet node is on the other end of each one? More
importantly, how does DECnet deal with that?? If a single instance of your Multinet DECnet over
IP tunnel driver can talk to more than one remote client at once, then you have a single
DECnet circuit with multiple adjacencies on the other end. This is like Ethernet, not a
point to point circuit. How does DECnet deal with that?
No. Each link is a single point-to-point circuit.
It's just that I define links that use the same local port number, but
there can be several connections/circuits that use that local port, but
with different remote endpoints. In DECnet, they will be separate circuits.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol