HECnet

hecnet@lists.dfupdate.se

15589 discussions

by wonko＠4amlunch.net

On 1/7/2013 1:59 PM, Ian McLaughlin wrote: On 2013-01-07, at 10:54 AM, Cory Smelosky <b4 at gewt.net> wrote: What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff... I have a Cisco 7206VXR router that has Cisco's Decnet implementation on it. It is now acting as my area router, and connects to Dave's Cisco via an IP tunnel. From what I understand, Cisco's Decnet implementation is proprietary - not sure if it works well with non-Cisco stuff. Ian Cisco's DECnet is, well, DECnet. :) There is nothing special about the tunnel. It's just a bog standard GRE tunnel (or you could use an IPSec tunnel if you wanted to). The Cisco just talks DECnet on all the links you tell it to. As far as replicating it, you'd need something that can route DECnet and can talk GRE, that's all it would take. Good luck finding that though. :) -brian

13 years, 1 month

Area 48.....

by Paul_Koning＠Dell.com

On Jan 7, 2013, at 1:52 PM, Ian McLaughlin wrote: Wouldn't it be ironic if Hecnet ran out of addresses :) Does anyone know what the largest DECnet deplayment was duing the good old days? The internal net at DEC was seriously out of addresses, though just like IP that's partly because the addressing scheme forced it to be somewhat sparse. Still, there were certainly tens of thousands of nodes on it. paul

13 years, 1 month

Area 48.....

by b4＠gewt.net

On 7 Jan 2013, at 13:59, Ian McLaughlin <ian at platinum.net> wrote: On 2013-01-07, at 10:54 AM, Cory Smelosky <b4 at gewt.net> wrote: What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff... I have a Cisco 7206VXR router that has Cisco's Decnet implementation on it. It is now acting as my area router, and connects to Dave's Cisco via an IP tunnel. From what I understand, Cisco's Decnet implementation is proprietary - not sure if it works well with non-Cisco stuff. Ah, I probably couldn't use it on my stuff then. Ian

13 years, 1 month

Area 48.....

by ian＠platinum.net

On 2013-01-07, at 10:54 AM, Cory Smelosky <b4 at gewt.net> wrote: What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff... I have a Cisco 7206VXR router that has Cisco's Decnet implementation on it. It is now acting as my area router, and connects to Dave's Cisco via an IP tunnel. From what I understand, Cisco's Decnet implementation is proprietary - not sure if it works well with non-Cisco stuff. Ian

13 years, 1 month

Area 48.....

by b4＠gewt.net

On 7 Jan 2013, at 13:52, Ian McLaughlin <ian at platinum.net> wrote: Wouldn't it be ironic if Hecnet ran out of addresses :) Does anyone know what the largest DECnet deplayment was duing the good old days? I wonder if HECnet has overtaken it in size. ;) Ian p.s. Johnny, just in case you've still got the bindings in your bridge for area 42, you can remove them. Thanks to Dave McGuire, I've now got my Cisco router connected to him. Is there anyone else on Hecnet offering Cisco tunnels that I could set up for redundancy? What kind of cisco tunnel? I'm curious as to if I could replicate any of that setup with open source stuff... On 2013-01-07, at 10:44 AM, sampsa at mac.com wrote: Johnny, As I've just moved to Beirut (well Dahab at the moment temporarily) and intend to keep areas 8 and 47 up and running, any chance I could get 48 for myself too? Was thinking of a PPTP VPN and then multinet to area 8.. sampsa

13 years, 1 month

Area 48.....

by ian＠platinum.net

Wouldn't it be ironic if Hecnet ran out of addresses :) Does anyone know what the largest DECnet deplayment was duing the good old days? Ian p.s. Johnny, just in case you've still got the bindings in your bridge for area 42, you can remove them. Thanks to Dave McGuire, I've now got my Cisco router connected to him. Is there anyone else on Hecnet offering Cisco tunnels that I could set up for redundancy? On 2013-01-07, at 10:44 AM, sampsa at mac.com wrote: Johnny, As I've just moved to Beirut (well Dahab at the moment temporarily) and intend to keep areas 8 and 47 up and running, any chance I could get 48 for myself too? Was thinking of a PPTP VPN and then multinet to area 8.. sampsa

13 years, 1 month

Area 48.....

by sampsa＠mac.com

Johnny, As I've just moved to Beirut (well Dahab at the moment temporarily) and intend to keep areas 8 and 47 up and running, any chance I could get 48 for myself too? Was thinking of a PPTP VPN and then multinet to area 8.. sampsa

13 years, 1 month

DMC11 in next simh version... looks nice, and question about TOPS-10

by Paul_Koning＠Dell.com

On Jan 6, 2013, at 8:55 PM, Gerardo Cacciari wrote: On Sat, 5 Jan 2013 01:31:36 +0000, you wrote: Finally, in the DMC a buffer corresponds one to one with a DDCMP packet (its implementation of property 3). That's required -- all DECnet protocols are packet oriented and packet boundaries are meaningful. There are no byte stream protocols in DECnet -- TCP is the only protocol among all the networking protocols I know of that made that horrible design error. Sorry to bother you, but right in these days I'm reading and learning something more about transmission protocols (such as BSC, SDLC, and DDCMP), and your statement about that TCP design error tickled my curiosity. I know that BSC and DDCMP can be defined as character oriented protocols, while things like SDLC (and all its derivatives) are bit oriented; there are other differences but this is the most striking one. But let's not digress. I'd relate TCP to DECnet NSP, rather than to DDCMP, and if I'm not wrong both protocols (and DDCMP too) have variable length packets, according to how much data they have to send at the moment. So, can't they both be defined byte stream protocols? Or maybe are you referring to the fact that while NSP and DDCMP have a per-packet acknowledgement, TCP acknowledges single bytes and so can theoretically acknowledge just the first N bytes of a given packet? Yes, TCP has variable length packets, as do the other protocols. The essence of "stream oriented protocol" is not in the packet format. Instead, it is in the definition of the service provided to the application. In TCP, the service provided is a stream of bytes delivered to the other end. The stream has no structure. In every other networking protocol (including, ironically, UDP) the service provided is delivery of a sequence of packets to the other end. A packet is a number of bytes AND a specific packet boundary. For example, if in TCP I send 10 bytes then 20 bytes, the receiver may see 30 bytes delivered all at once, or a delivery of 5 bytes followed by 25 bytes, or 6 deliveries of 5 bytes each. Some of those are not likely in practice, but all are valid. On the other hand, in DECnet (or UDP, or ISO transport) if I send a 10 byte packet then a 20 byte packet, the receiver sees a 10 byte packet followed by a 20 byte packet. Nothing else is possible. All applications need structured data of some sort. So what happens is that every application has to make up for the fact that TCP doesn't do a packet service by layering a packet delimiting scheme on top. Often that comes in the form of a header that contains a data length, then you count off that many bytes, and then you look for another header. If you ever get out of sync, you end up looking for a header in the wrong place and the protocol won't recover until you close the connection and restart. Also, in the real world under the covers, you always have packets. So you would think that in reality, a high speed application (like iSCSI) could just assume that its headers are always found at the start of TCP buffers. And yes, that's a valid optimization, but you can NOT rely on that being true 100% of the time, because it's only a "likely" behavior, not a guarantee that's part of the TCP service definition. By contrast, if you implemented iSCSI on top of DECnet, or OSI, you would simply have the iSCSI PDUs starting at the start of a transport layer SDU, and this whole mess would disappear. Your code would be much smaller and more reliable because you no longer have to allow for the "unlikely" case of application PDUs starting in the middle of a TCP data delivery, or worse yet, straddling a boundary. Incidentally, there's a successor to TCP called SCTP that has packet service, and it would be a great solution to all this if only it were in general use -- but it isn't. paul

13 years, 1 month

DU11 vs. DUV11

by bqt＠softjar.se

On 2013-01-06 22:06, Steve Davidson wrote: -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Sunday, January 06, 2013 15:54 To: hecnet at Update.UU.SE Cc: John Wilson Subject: Re: [HECnet] DU11 vs. DUV11 On 2013-01-06 21:47, John Wilson wrote: I still can't find where it says "8085A" in the 110/130 manual, but page B-3 gives I/O page timings and mentions an "I/O microprocessor" and the fact that word I/O takes 90 usec but byte I/O takes 180 usec. So that certainly explains the difference in the DUV driver. Plus the manual specifically says that RSX11S is available for the /110, so I guess it was even supported! Sweet. Also mentioned on page 4-6, but pretty much with the same level of detail. Byte writes cause a read-modify-write. Time of 180 usec. And there is an (unmentioned) 8-bit microprocessor acting in between the PDP-11 and any peripherials. 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 I just found my VT103 LSI-11 Video Terminal User's Guide. The beast looks like a VT100 but has dual, count them dual, TU58's in the front and a 4x4 18-bit backplane in the back. Typical configuration (slot-wise) is: 1 - LSI-11 Processor 2 - MSV11-DD memory 3 - DJV11-J (4-channel serial line interface) Or 1 - LSI-11 Processor 2 - MVX11-A memory and serial in/out The bus slots are numbered from 0-7. I will look for my PDT documentation a little later. I am cleaning up that part of the basement now anyway. I actually have a couple of VT103, but I've never laid my hands on any PDT-11, which is why I (obviously) don't know enough about them. 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

13 years, 1 month

DU11 vs. DUV11

by jeep＠scshome.net

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Sunday, January 06, 2013 15:54 To: hecnet at Update.UU.SE Cc: John Wilson Subject: Re: [HECnet] DU11 vs. DUV11 On 2013-01-06 21:47, John Wilson wrote: I still can't find where it says "8085A" in the 110/130 manual, but page B-3 gives I/O page timings and mentions an "I/O microprocessor" and the fact that word I/O takes 90 usec but byte I/O takes 180 usec. So that certainly explains the difference in the DUV driver. Plus the manual specifically says that RSX11S is available for the /110, so I guess it was even supported! Sweet. Also mentioned on page 4-6, but pretty much with the same level of detail. Byte writes cause a read-modify-write. Time of 180 usec. And there is an (unmentioned) 8-bit microprocessor acting in between the PDP-11 and any peripherials. 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 I just found my VT103 LSI-11 Video Terminal User's Guide. The beast looks like a VT100 but has dual, count them dual, TU58's in the front and a 4x4 18-bit backplane in the back. Typical configuration (slot-wise) is: 1 - LSI-11 Processor 2 - MSV11-DD memory 3 - DJV11-J (4-channel serial line interface) Or 1 - LSI-11 Processor 2 - MVX11-A memory and serial in/out The bus slots are numbered from 0-7. I will look for my PDT documentation a little later. I am cleaning up that part of the basement now anyway. -Steve

13 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet