<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I have always wondered whether 'Multinet' might have been a
      figment of some marketeer's imagination.  DEC's sales people had
      some remarkable gaffs, particularly when transitioning from the 36
      to 32 bit line.  But I'm sure they were not unique in that regard.<br>
    </p>
    <div class="moz-cite-prefix">
      <p>Under Tops-20, 'Multinet' has a <u>very</u> specific meaning;
        it is the MNETDV module (the Multinet driver) is what handles
        routing IP packets over different physical media, in this case,
        an AN20 (to an IMP), an NI and CI.</p>
    </div>
    <div class="moz-cite-prefix">
      <p>I can't remember what equivalent for DECnet is called in 36 bit
        land, but it can be routed over a CI, an NI or over a DTE to
        DN20 (MCB).  There are some additional devices, but I don't know
        if they were implemented; I think ROUTER.MAC handles some of
        that.<br>
      </p>
    </div>
    <blockquote type="cite"
      cite="mid:2BEDDDBD-A05C-410D-935F-FDC54E13E464@comcast.net">
      <hr width="100%" size="2">
      <pre class="moz-quote-pre" wrap="">On 3/28/2021 1:52 PM, Paul Koning wrote:

I didn't see that.

I have never used the product called Multinet myself.  When I use the term "Multinet" it has always referred to the encapsulation of DECnet point to point routing packets with a 4 byte header, sent either as UDP packets or over a TCP stream.  This is what I understand to be the so-called "Multinet datalink" (which as I have said many times isn't an actual datalink and reflects only the utter ignorance of its creators).  That "protocol" should be avoided; if there is no alternative then only the TCP variant should be used.  The UDP variant is utterly unfit for any use in any application whatsoever and always has been; I should probably delete it from PyDECnet rather than permit it with a warning as I currently do.

If the product called Multinet also supports DDCMP, that's a different matter entirely.  I have never heard of any such thing.  How does it work?  Is it compatible with DDCMP over TCP as implemented in SIMH?  If yes -- and even if it only supports only connect or listen but not both concurrently as SIMH does -- it should work with PyDECnet.  I'd be interested in hearing about it.  If it isn't compatible with the SIMH version for some other reason, then I would expect it not to work with PyDECnet either.  If so, and if someone can supply me with a description of how it operates, hopefully with at least some protocol captures, I may be able to add support for it.

        paul
</pre>
      <blockquote type="cite">
        <hr width="100%" size="2">
        <pre class="moz-quote-pre" wrap="">On Mar 28, 2021, at 12:59 PM, Robert Armstrong <a class="moz-txt-link-rfc2396E" href="mailto:bob@jfcl.com"><bob@jfcl.com></a> wrote:

 Johnny already said it, but it's worth repeating that Multinet WILL do DDCMP over TCP (yes, TCP not UDP) if you ask it to.  It's unfortunately not the default, but it's easy to change.

Bob
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap=""><blockquote type="cite"><pre class="moz-quote-pre" wrap=""><blockquote type="cite"><hr width="100%" size="2"><pre class="moz-quote-pre" wrap=""><pre class="moz-quote-pre" wrap="">Paul Koning <a class="moz-txt-link-rfc2396E" href="mailto:paulkoning@comcast.net"><paulkoning@comcast.net ></a> wrote:
No, you're confusing DDCMP and Multinet.
Multinet isn't a datalink protocol; it's merely a wrapper for
the routing layer packets.
</pre></pre></blockquote></pre></blockquote></pre>
    </blockquote>
  </body>
</html>