On 05/01/12 16:21, Mark Benson wrote:
What is the INFO.TXT you guys are talking about? Should I have one on STAR69 with my node list in?
Mark,
The HECNET INFO.TXT files is located in the default directory for the FAL$SERVER account, which is referenced from other nodes using <NODENAME>::INFO.TXT - for example SLAVE::INFO.TXT
[MSW]SLAVE$ type slave::info.txt
Marks Office, Windermere, UK
(a working set of computers - definitely not a 'collection' ;)
BUBBLE and SLAVE serve the HECnet.eu website via WASD
BUBBLE has a captive account, NETHACK, password NETHACK for playing, you guessed it, nethack.
http://www.hecnet.eu
- HECnet.eu website
http://www.wickensonline.co.uk
- My personal website
http://blog.wickensonline.co.uk
- My BLOG
.BEGIN-HECNET-INFO
ADDR |NAME |OWNER |EMAIL |HARDWARE |OS |LOCATION |NOTES
4.249|SLAVE |Mark Wickens|mark_at_hecnet.eu|AlphaServer 1000A |OpenVMS 8.3 |Windermere,UK|WASD
4.250|ORAC | | |VAXstation 4000/90 |OpenVMS 7.3 | |ALLIN1
4.251|ZX6000| | |HP IA64 ZX6000 |OpenVMS 8.3.1-H1| |16GB RAM
4.252|NODE3 | | |DEC 3000/600 AXP |OpenVMS 8.3 | |
4.253|NODE2 | | |Compaq DS10L |OpenVMS 8.3 | |
4.254|ZEN | | |VAXstation 4000/60 |OpenVMS 7.3 | |Clustered
4.255|X60 | | |IBM X60 Thinkpad |Ubuntu,WinXP | |
4.256|BUBBLE| | |VAXstation 4000/90 |OpenVMS 7.3 | |Nethack,WASD
4.257|ELLEN | | |DEC 3000/600 AXP |DUnix 4.0G | |
4.258|TIGER | | |Alpha 300 4/266 |DUnix 5.1 | |
4.259|ALEPH | | |VAXstation 4000/VLC|OpenVMS 7.3 | |Clustered
.END-HECNET-INFO
Arbitrary text before the text: .BEGIN-HECNET-INFO
The the format as specified followed by: .END-HECNET-INFO
I've been meaning to do something with these for ages and add some more info to hecnet.eu, but I held off because I wasn't sure whether people wanted this level of information available across the internet.
Regards, Mark.
And now I'm seeing quite a bit more traffic on my router!
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Bob Armstrong
Sent: Thu 1/5/2012 11:14
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Multinet circuit costs
where DECnet *might* get confused.
Well, this is easy enough to test experimentally. I've disabled the
redundant Multinet links on LEGATO, so in theory there should be no
redundancy now at least as far as LEGATO goes.
This means not only disabling the direct links from LEGATO to other bridge
nodes (e.g. GORVAX, SG1) but _also_ the links from LEGATO to other nodes
that in turn have Multinet links to bridge nodes (STUPI, FRUGAL, ROOSTA).
In theory I suppose the latter step is excessive since we can assume that a
two hop path would always cost more than a one hop path, but there's no
guarantee of that. So just to be safe this absolutely eliminates redundant
paths.
I think that leaves me with area 54, CIERE, as the only machine that
_only_ gets its connectivity thru LEGATO. That link I've left turned on.
Now LEGATO sees the path to everything except CEIRE as being thru the
bridge (QNA-1), which is what we'd expect.
OpenVMS Network status for local node 2.1 LEGATO on 5-JAN-2012
08:11:19.43
Area Cost Hops Next Hop to Area
1 4 1 QNA-1 -> 1.300 CTAKAH
2 0 0 (Local) -> 2.1 LEGATO
3 7 2 QNA-1 -> 19.41 SG1
4 4 1 QNA-1 -> 4.249 SLAVE
5 14 4 QNA-1 -> 19.41 SG1
6 4 1 QNA-1 -> 6.1 STAR69
8 7 2 QNA-1 -> 19.41 SG1
11 4 1 QNA-1 -> 11.2 MAISA
19 4 1 QNA-1 -> 19.41 SG1
20 14 2 QNA-1 -> 19.41 SG1
33 7 2 QNA-1 -> 19.41 SG1
42 4 1 QNA-1 -> 42.1 CANADA
52 10 3 QNA-1 -> 19.41 SG1
54 2 1 TCP-0-54 -> 54.59 CEIRE
59 7 2 QNA-1 -> 19.41 SG1
Try your file copies again and see if anything changes...
Bob
Works for me!
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Oleg Safiullin
Sent: Thu 1/5/2012 11:35
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Router for area 1
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Hmm.
CTAKAH is set to lower router priority than MIM. I thought this is enough to tell that MIM is preffered router...
There's no need for CTAKAH to be and area router, so I'll downgrade it to endnode...
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Hmm.
CTAKAH is set to lower router priority than MIM. I thought this is enough to tell that MIM is preffered router...
There's no need for CTAKAH to be and area router, so I'll downgrade it to endnode...
I wrote-
OpenVMS Network status for local node 2.1 LEGATO on 5-JAN-2012
08:11:19.43
Area Cost Hops Next Hop to Area
1 4 1 QNA-1 -> 1.300 CTAKAH
....
It bugs me, although I can't point at an actual problem that it causes,
that the routing node for area 1 is seen as CTAKAH, rather than MIM. Since
CTAKAH is not actually local to Uppsula (I think that's where MIM is) but is
rather at the other end of yet another bridge, this means that any traffic
for area one, no matter what its ultimate destination, has to make an extra
round trip to Russia.
This happens because when there are multiple routing nodes for the same
area, DECnet uses the one with the highest address. The obvious solution
would be for Johnny to renumber MIM as, say, 1.1023.
Bob
On 5 Jan 2012, at 15:58, "Steve Davidson" <jeep at scshome.net> wrote:
It could be the issue. If you are running Phase-IV then NETCONFIG will allow you to create the necessary account(s). You have a choice of creating a default DECnet account, or creating a FAL$SERVER account, or both. I have both contrary to what DEC's Inspect software would prefer.
Thanks for the heads-up I'll sort that out this evening.
What is the INFO.TXT you guys are talking about? Should I have one on STAR69 with my node list in?
HECnet is a closed society, so I don't worry about it.
Ha, wasn't a security issue as much as a clueless operator issue ;)
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
where DECnet *might* get confused.
Well, this is easy enough to test experimentally. I've disabled the
redundant Multinet links on LEGATO, so in theory there should be no
redundancy now at least as far as LEGATO goes.
This means not only disabling the direct links from LEGATO to other bridge
nodes (e.g. GORVAX, SG1) but _also_ the links from LEGATO to other nodes
that in turn have Multinet links to bridge nodes (STUPI, FRUGAL, ROOSTA).
In theory I suppose the latter step is excessive since we can assume that a
two hop path would always cost more than a one hop path, but there's no
guarantee of that. So just to be safe this absolutely eliminates redundant
paths.
I think that leaves me with area 54, CIERE, as the only machine that
_only_ gets its connectivity thru LEGATO. That link I've left turned on.
Now LEGATO sees the path to everything except CEIRE as being thru the
bridge (QNA-1), which is what we'd expect.
OpenVMS Network status for local node 2.1 LEGATO on 5-JAN-2012
08:11:19.43
Area Cost Hops Next Hop to Area
1 4 1 QNA-1 -> 1.300 CTAKAH
2 0 0 (Local) -> 2.1 LEGATO
3 7 2 QNA-1 -> 19.41 SG1
4 4 1 QNA-1 -> 4.249 SLAVE
5 14 4 QNA-1 -> 19.41 SG1
6 4 1 QNA-1 -> 6.1 STAR69
8 7 2 QNA-1 -> 19.41 SG1
11 4 1 QNA-1 -> 11.2 MAISA
19 4 1 QNA-1 -> 19.41 SG1
20 14 2 QNA-1 -> 19.41 SG1
33 7 2 QNA-1 -> 19.41 SG1
42 4 1 QNA-1 -> 42.1 CANADA
52 10 3 QNA-1 -> 19.41 SG1
54 2 1 TCP-0-54 -> 54.59 CEIRE
59 7 2 QNA-1 -> 19.41 SG1
Try your file copies again and see if anything changes...
Bob
It could be the issue. If you are running Phase-IV then NETCONFIG will allow you to create the necessary account(s). You have a choice of creating a default DECnet account, or creating a FAL$SERVER account, or both. I have both contrary to what DEC's Inspect software would prefer. HECnet is a closed society, so I don't worry about it.
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Mark Benson
Sent: Thu 1/5/2012 10:55
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet circuit costs
On 5 Jan 2012, at 15:40, hvlems at zonnet.nl wrote:
Yes I have problems wihile copying files from Legato and Star69 to Ozon.
STAR69 has no public user account, and IIRC won't allow file access via DECnet without a username and password. I haven't got around to figuring out how to set up non-privileged file access in a safe directory yet.
Could this be the issue? I really am a total newbie so STAR69's capabilities are the absolute minimum needed to do it's job at present.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
The circuit costs here are set to 4 for LAN and 3 for tunnels. The issue may be that if a node (at the end of the chain so to speak) has 2 tunnel links of the same cost and that the final destination costs the same I could see where DECnet *might* get confused. Let's look at the following contrived example:
FRUGAL:: connects to LEGATO:: - cost of 3
FRUGAL:: connects to SG1:: - cost of 3
LEGATO:: connects to GORVAX:: - cost of 3
SG1:: connects to GORVAX:: - cost of 3
Fred, on node FRUGAL:: tries to copy a (large) file from GORVAX:: to FRUGAL:: *may* see some issues. On the other hand if Fred chooses to favor SG1:: over LEGATO:: (cost wise) he should not see any problems: Ex:
FRUGAL:: connects to LEGATO:: - cost of 3
FRUGAL:: connects to SG1:: - cost of 2
The route is guaranteed to be the same for the entire transaction. It will be (using poor man's routing to demonstrate) FRUGAL::SG1::GORVAX:: at a cost of 5, not FRUGAL::LEGATO::GORVAX:: at a cost of 6.
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of hvlems at zonnet.nl
Sent: Thu 1/5/2012 10:43
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet circuit costs
PS
I can copy to Legato alright.
PPS
I did check the netserver.log files and found nothing out of the order.
On 5 Jan 2012, at 15:40, hvlems at zonnet.nl wrote:
Yes I have problems wihile copying files from Legato and Star69 to Ozon.
STAR69 has no public user account, and IIRC won't allow file access via DECnet without a username and password. I haven't got around to figuring out how to set up non-privileged file access in a safe directory yet.
Could this be the issue? I really am a total newbie so STAR69's capabilities are the absolute minimum needed to do it's job at present.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Again, apologies for topposting: my cellphone is somewhat rude...
PST is UTC-8 (unless Bob lives in the Philippines, then it's UTC+8 :).
Yes I have problems wihile copying files from Legato and Star69 to Ozon.
Ozon is the area router for area 44 and uses the bridge software.
I can't access the Hecnet map but Legato has multiple paths and IIRC so does Star.
Ozon has no problem copying files from MIM or MUSIPC and both are connected with single paths (IIRC again).
Reading Bob's analysis I still think that multiple paths may lead to errors. Granted that circuit cost may fix this but right now it is, for me at least, not clear.
The area information in the output of show network/old on Ozon shows all areas and about 40% is more than 1 hop away and seen as reachable thru Legato.
Hans
-----Original Message-----
From: "Bob Armstrong" <bob at jfcl.com>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 5 Jan 2012 07:14:50
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: RE: [HECnet] Multinet circuit costs
Why? What is the percieved problem?
I don't know about area 44, but I was talking to Hans on New Years Eve
about a problem where he could not copy files, while logged in to OZON, from
LEGATO (i.e. a "pull" transaction). According to Hans, it fails with "acp
file or directory lookup failed". If I did the same thing from my end (a
"push") it would start copying and actually create an empty file on OZON,
but then time out after a very long time with
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-LINKABORT, network partner aborted logical link
Last I heard Hans was going to check the NETSERVER/FAL logs on his side for
any error messages, but that was New Years Eve and he was otherwise occupied
:-)
I see this morning that Hans has actually created a file "TARGET.TXT" on
LEGATO (dated 6PM PST on 12/31 even - what time is that in the
Netherlands??) so maybe he's solved the problem. If he did he didn't tell
me what he did.
Hans also mentioned to me that he was having similar problems with the
node STAR69 and CANADA. I think all this came up when Hans was trying to
write his HECnet crawler script to gather INFO.TXT files...
I don't think this is related to the Multinet/Bridge configuration, but I
can't guarantee it. One hidden "gotcha" in DECnet is that the circuit costs
are determined locally, so the routings don't have to be symmetrical (i.e.
the route from A->B might not be the same as the route from B->A).
If somebody (Johnny??) wants to try to figure it out, be my guest -
GUEST/GUEST. I'm a little busy at the moment and don't really have time to
look at it.
Bob
Why? What is the percieved problem?
I don't know about area 44, but I was talking to Hans on New Years Eve
about a problem where he could not copy files, while logged in to OZON, from
LEGATO (i.e. a "pull" transaction). According to Hans, it fails with "acp
file or directory lookup failed". If I did the same thing from my end (a
"push") it would start copying and actually create an empty file on OZON,
but then time out after a very long time with
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-LINKABORT, network partner aborted logical link
Last I heard Hans was going to check the NETSERVER/FAL logs on his side for
any error messages, but that was New Years Eve and he was otherwise occupied
:-)
I see this morning that Hans has actually created a file "TARGET.TXT" on
LEGATO (dated 6PM PST on 12/31 even - what time is that in the
Netherlands??) so maybe he's solved the problem. If he did he didn't tell
me what he did.
Hans also mentioned to me that he was having similar problems with the
node STAR69 and CANADA. I think all this came up when Hans was trying to
write his HECnet crawler script to gather INFO.TXT files...
I don't think this is related to the Multinet/Bridge configuration, but I
can't guarantee it. One hidden "gotcha" in DECnet is that the circuit costs
are determined locally, so the routings don't have to be symmetrical (i.e.
the route from A->B might not be the same as the route from B->A).
If somebody (Johnny??) wants to try to figure it out, be my guest -
GUEST/GUEST. I'm a little busy at the moment and don't really have time to
look at it.
Bob
Well...
Sampsa's network and mine have been running both the bridge and the tunnels for a very long time. As long as we manage the costs (keep the tunnels lower cost) things run great! We still need to determine what those costs should be. I have some ideas that I will share in a follow-up message based on experience. Multiple paths are not a problem, DECnet sorts this out. Once we get something that resembles a map then we can set a costs policy and things WILL be back on track.
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of hvlems at zonnet.nl
Sent: Thu 1/5/2012 02:48
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet circuit costs
DECnet supports multiple paths between hosts (e.g. Ethernet and CI) and circuit cost is a way to favour one path over another.
In situations where a bridge and a Multinet TCP tunnel operate in parallel that still leads to multiple paths. Even if the TCP tunnel has the lowest cost the ethernet path will send out multicast messages. I think that is the reason LEGATO has issues (cannot copy files to area 44) and possibly why MIM now sees a different world.
The map shows several parallel paths. I'd suggest in stead of modifying cost it is better to have either the bridge program or a TCP tunnel per site for a couple of days and see what happens.
Hans
------Origineel bericht------
Van: Johnny Billquist
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Multinet circuit costs
Verzonden: 5 januari 2012 00:48
On 2012-01-04 23.31, Steve Davidson wrote:
Have we decided on what the circuit costs should be set to for the
Multinet circuits? I just did:
NCP TELL MIM SHOW KNOW AREAS
and discovered that MIM's view of the world has changed. From what I can
tell it is due to changes is circuit costs. I have made no changes at my
end. I was waiting for consensus before making any changes.
-Steve
I don't know if a general consensus was reached, but I agree with the
idea expressed. When you have both the bridge, and Multinet DECnet
tunneled, make the costs for the Multinet circuits lower.
Yes, the changes made by some have had effect on how the routing from
MIMs point of view looks. And I think it's an improvement. A few
destinations farther away that I tested against were noticeable faster now.
Johnny
Sorry about being unclear.
Among the advantages of DDCMP is that it works on any link that can transmit 8 bit byte values, that's all it cares about. Bisync has the same property, but HDLC does not (it has much stricter requirements). That's why DDCMP works on both sync and async links essentially without any change (and for that matter works, at least in principle, on an 8 bit parallel link such as a classic PC printer port, though I don't know that it has actually been used on parallel links in the real world). The same goes for Bisync (if you can speak of that protocol "working" at all, bletch); I remember having the distinct lack of pressure debugging an application that used bisync across DL11-E async links.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Thursday, January 05, 2012 1:37 AM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Hecnet and DDCMP
Excellent. Then it do not require anything more than a link that can
transport a stream of bytes.
You made it sound (to me), as if DDCMP expected the underlying link to
provide more structure, which is what I wanted to check.
Johnny
On 2012-01-05 02.23, Paul_Koning at Dell.com wrote:
Yes, DDCMP does its own block delimiting on both sync and async lines, basically the same way for both. It recognizes the header by byte patterns plus good CRC, and the payload framing is controlled by the payload byte count that's mentioned in the header.
It's all in the spec. Take a look, it's a very clear and very simple document.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Wednesday, January 04, 2012 6:46 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Hecnet and DDCMP
On 2012-01-04 23.15, Paul_Koning at Dell.com wrote:
I assume there has to be a bit more to it, because DDCMP is a packet based protocol
(not a stream protocol as TCP is) and the higher layers rely on that. So there
presumably is some form of framing in the emulated data stream to indicate where the
packet boundaries are.
Paul, how does this work when you have DDCMP over an asynch serial line?
There are no frames there. It is just a stream of bytes at the physical
layer, exactly the same as TCP for example. Yet, DDCMP talks over that
too... DDCMP must be implementing the blocking/deblocking on its own in
that case.
Johnny
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Rob Jarratt
Sent: Wednesday, January 04, 2012 5:11 PM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
All I do in SIMH is to take the data bytes each end wants to send to the other end and send them over a socket, so I don't get involved with DDCMP itself. Both ends have to be SIMH for this to work. I don't do anything at the actual hardware level, although that would be nice. I think you can get synchronous serial cards for the PC but they are quite expensive.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 03 January 2012 21:18
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
DMC-11 speaks DDCMP V3.1 (give or take some bugs in the "high speed"
version). But that's sync only. Depending on what you want to talk
to, a
DMC
(or its relatives DMR-11, DMP-11, or DMV-11) may not help; if the
other
end
speaks DDCMP over an async link (UART) then it won't work because the
character framing doesn't match.
That said, I wonder what it means to emulate a DMC-11. You could have
it speak DDCMP over a UART, or something else entirely. If the former
it
would
talk to another DDCMP node; if the latter it would not but it would
still
work
for tying one emulated DMC-11 to another.
If you want DDCMP, one approach is to get a copy of the spec, and
implement
what it says. That works; it is how I implemented DDCMP support for
RSTS
V10
(based on an earlier version based on V9.6). The protocol is quite
simple
and
the spec is well enough written that, if you do what it says, the
result
WILL
interoperate with hardware such as the DMR-11. The only tricky one is
the
DMC-11 because it has some undocumented bugs; the main one I remember
is that the high speed version can't handle back to back packets. I
wish
I could
contribute the code I wrote but I can't, for various reasons one of
them
is that
it's a RSTS device driver and written in 100% assembly language.
It would not be hard to do a version for other platforms; I once
looked at
a
Linux terminal protocol handler (forgot what that is called) that
could
hook
into DECnet/Linux. Didn't get far enough on that, though.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Mark Abene
Sent: Sunday, January 01, 2012 6:06 PM
To: hecnet at update.uu.se
Subject: Re: [HECnet] Hecnet and DDCMP
Jarratt, did you make this publicly available on the SIMH list? It
would
be great
to have a DMC11 device emulated, since I insist on running RSTS/E v8
(for historical reasons... it was the last real RSTS before "the pollution").
RSTS/E v8
doesn't have ethernet support, so the only way I could have DECnet is
via
a
(previously unemulated)
DMC11 interface. Does yours work well?
-Mark
On Sun, Jan 1, 2012 at 3:23 AM, Jarratt RMA
<robert.jarratt at ntlworld.com>
wrote:
Working with a friend, I have written a SIMH emulation of the DMC11
device, so you can do this with SIMH. It tunnels the bytes sent
to/from the device over a socket. We have used the SIMH emulation to
connect my friend to HECnet over a (simulated) DMC11.
The bit I am not entirely sure about is to what extent this is using
DDCMP as I don't have a full understanding of DDCMP.
Regards
Rob
On 31 December 2011 18:46, The Presence<tpresence at hotmail.com>
wrote:
Hey guys,
Has anyone worked out a mechanism to connect a node to hecnet using
DDCMP?
Perhaps some tunneling technology over IP, or virtualized serial?
Kevin
Why? What is the percieved problem?
For MIM atleast, the changes in the routing tables were expected, and benifical. From MIMs point of view, the network worked before, and works now. However, it now works better, as response times for areas far away have improved.
What is the problem at LEGATO? I haven't heard anything, but if there is a problem there, we should try and figure out why. The fact that there are multiple paths should not be a problem. Yes, there is still broadcast packets on all links, just as before. Nothing have changed from that point of view. But in some situations, actual traffic will now take different paths than before. In almost all situations, this should be when there are multiple hops to get to the destination. And traffic will now favor multinet links a bit more.
But unless someone really place a much higher cost on their ethernet circuit, it will not be unreasonably favoritism of multinet links.
Johnny
On 2012-01-05 08.48, hvlems at zonnet.nl wrote:
DECnet supports multiple paths between hosts (e.g. Ethernet and CI) and circuit cost is a way to favour one path over another.
In situations where a bridge and a Multinet TCP tunnel operate in parallel that still leads to multiple paths. Even if the TCP tunnel has the lowest cost the ethernet path will send out multicast messages. I think that is the reason LEGATO has issues (cannot copy files to area 44) and possibly why MIM now sees a different world.
The map shows several parallel paths. I'd suggest in stead of modifying cost it is better to have either the bridge program or a TCP tunnel per site for a couple of days and see what happens.
Hans
------Origineel bericht------
Van: Johnny Billquist
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Multinet circuit costs
Verzonden: 5 januari 2012 00:48
On 2012-01-04 23.31, Steve Davidson wrote:
Have we decided on what the circuit costs should be set to for the
Multinet circuits? I just did:
NCP TELL MIM SHOW KNOW AREAS
and discovered that MIM's view of the world has changed. From what I can
tell it is due to changes is circuit costs. I have made no changes at my
end. I was waiting for consensus before making any changes.
-Steve
I don't know if a general consensus was reached, but I agree with the
idea expressed. When you have both the bridge, and Multinet DECnet
tunneled, make the costs for the Multinet circuits lower.
Yes, the changes made by some have had effect on how the routing from
MIMs point of view looks. And I think it's an improvement. A few
destinations farther away that I tested against were noticeable faster now.
Johnny
DECnet supports multiple paths between hosts (e.g. Ethernet and CI) and circuit cost is a way to favour one path over another.
In situations where a bridge and a Multinet TCP tunnel operate in parallel that still leads to multiple paths. Even if the TCP tunnel has the lowest cost the ethernet path will send out multicast messages. I think that is the reason LEGATO has issues (cannot copy files to area 44) and possibly why MIM now sees a different world.
The map shows several parallel paths. I'd suggest in stead of modifying cost it is better to have either the bridge program or a TCP tunnel per site for a couple of days and see what happens.
Hans
------Origineel bericht------
Van: Johnny Billquist
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Multinet circuit costs
Verzonden: 5 januari 2012 00:48
On 2012-01-04 23.31, Steve Davidson wrote:
Have we decided on what the circuit costs should be set to for the
Multinet circuits? I just did:
NCP TELL MIM SHOW KNOW AREAS
and discovered that MIM's view of the world has changed. From what I can
tell it is due to changes is circuit costs. I have made no changes at my
end. I was waiting for consensus before making any changes.
-Steve
I don't know if a general consensus was reached, but I agree with the
idea expressed. When you have both the bridge, and Multinet DECnet
tunneled, make the costs for the Multinet circuits lower.
Yes, the changes made by some have had effect on how the routing from
MIMs point of view looks. And I think it's an improvement. A few
destinations farther away that I tested against were noticeable faster now.
Johnny
Excellent. Then it do not require anything more than a link that can transport a stream of bytes.
You made it sound (to me), as if DDCMP expected the underlying link to provide more structure, which is what I wanted to check.
Johnny
On 2012-01-05 02.23, Paul_Koning at Dell.com wrote:
Yes, DDCMP does its own block delimiting on both sync and async lines, basically the same way for both. It recognizes the header by byte patterns plus good CRC, and the payload framing is controlled by the payload byte count that's mentioned in the header.
It's all in the spec. Take a look, it's a very clear and very simple document.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Wednesday, January 04, 2012 6:46 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Hecnet and DDCMP
On 2012-01-04 23.15, Paul_Koning at Dell.com wrote:
I assume there has to be a bit more to it, because DDCMP is a packet based protocol
(not a stream protocol as TCP is) and the higher layers rely on that. So there
presumably is some form of framing in the emulated data stream to indicate where the
packet boundaries are.
Paul, how does this work when you have DDCMP over an asynch serial line?
There are no frames there. It is just a stream of bytes at the physical
layer, exactly the same as TCP for example. Yet, DDCMP talks over that
too... DDCMP must be implementing the blocking/deblocking on its own in
that case.
Johnny
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Rob Jarratt
Sent: Wednesday, January 04, 2012 5:11 PM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
All I do in SIMH is to take the data bytes each end wants to send to the other end and send them over a socket, so I don't get involved with DDCMP itself. Both ends have to be SIMH for this to work. I don't do anything at the actual hardware level, although that would be nice. I think you can get synchronous serial cards for the PC but they are quite expensive.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 03 January 2012 21:18
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
DMC-11 speaks DDCMP V3.1 (give or take some bugs in the "high speed"
version). But that's sync only. Depending on what you want to talk
to, a
DMC
(or its relatives DMR-11, DMP-11, or DMV-11) may not help; if the
other
end
speaks DDCMP over an async link (UART) then it won't work because the
character framing doesn't match.
That said, I wonder what it means to emulate a DMC-11. You could have
it speak DDCMP over a UART, or something else entirely. If the former
it
would
talk to another DDCMP node; if the latter it would not but it would
still
work
for tying one emulated DMC-11 to another.
If you want DDCMP, one approach is to get a copy of the spec, and
implement
what it says. That works; it is how I implemented DDCMP support for
RSTS
V10
(based on an earlier version based on V9.6). The protocol is quite
simple
and
the spec is well enough written that, if you do what it says, the
result
WILL
interoperate with hardware such as the DMR-11. The only tricky one is
the
DMC-11 because it has some undocumented bugs; the main one I remember
is that the high speed version can't handle back to back packets. I
wish
I could
contribute the code I wrote but I can't, for various reasons one of
them
is that
it's a RSTS device driver and written in 100% assembly language.
It would not be hard to do a version for other platforms; I once
looked at
a
Linux terminal protocol handler (forgot what that is called) that
could
hook
into DECnet/Linux. Didn't get far enough on that, though.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Mark Abene
Sent: Sunday, January 01, 2012 6:06 PM
To: hecnet at update.uu.se
Subject: Re: [HECnet] Hecnet and DDCMP
Jarratt, did you make this publicly available on the SIMH list? It
would
be great
to have a DMC11 device emulated, since I insist on running RSTS/E v8
(for historical reasons... it was the last real RSTS before "the pollution").
RSTS/E v8
doesn't have ethernet support, so the only way I could have DECnet is
via
a
(previously unemulated)
DMC11 interface. Does yours work well?
-Mark
On Sun, Jan 1, 2012 at 3:23 AM, Jarratt RMA
<robert.jarratt at ntlworld.com>
wrote:
Working with a friend, I have written a SIMH emulation of the DMC11
device, so you can do this with SIMH. It tunnels the bytes sent
to/from the device over a socket. We have used the SIMH emulation to
connect my friend to HECnet over a (simulated) DMC11.
The bit I am not entirely sure about is to what extent this is using
DDCMP as I don't have a full understanding of DDCMP.
Regards
Rob
On 31 December 2011 18:46, The Presence<tpresence at hotmail.com>
wrote:
Hey guys,
Has anyone worked out a mechanism to connect a node to hecnet using
DDCMP?
Perhaps some tunneling technology over IP, or virtualized serial?
Kevin
No, that wouldn t work, because what Rob is saying is that he sends the length plus payload, but not a regular DDCMP header or either of the CRCs. So if you send that emulated DMC data stream to a real DDCMP implementation it would not recognize it because the headers are omitted.
It wouldn t be a large change, though. Compared to the job of emulating a DMC (the microcontroller to bus interface logic), DDCMP itself is a simple matter.
paul
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Kevin Reynolds Sent: Wednesday, January 04, 2012 5:43 PM To: hecnet at update.uu.se Subject: RE: [HECnet] Hecnet and DDCMP
There is a possibility to use a real system however, if a client was written that would read input from the socket and throw it out of the serial port on physical hardware? As long as the original data integrity is maintained this should work as long as timing isn't an issue, correct? You basically created a virtual driver that behaved as a serial adapter?
Was this done over TCP/IP or DecNET, or LAT or something else?
For synchronous comms (assuming DMC-11 RS232-C physical) you would need to use a 25 pin connector to wire it as it requires pins 15, 17 and 24 for the clock signal in addition to the standard async pins. It would just be a matter of putting in a microcontroller such as the launchpad or arduino to handle the synchronous communications, and then pass it back out async. Yes this would probably be very messy and perhaps the wrong way to go.
Regardless, I would love to see what you have done to get this working SIMH->SIMH.
Thanks heaps,
Kevin
> From: robert.jarratt at ntlworld.com > To: hecnet at Update.UU.SE > Subject: RE: [HECnet] Hecnet and DDCMP > Date: Wed, 4 Jan 2012 22:10:47 +0000 > > All I do in SIMH is to take the data bytes each end wants to send to the > other end and send them over a socket, so I don't get involved with DDCMP > itself. Both ends have to be SIMH for this to work. I don't do anything at > the actual hardware level, although that would be nice. I think you can get > synchronous serial cards for the PC but they are quite expensive. > > Regards > > Rob >
Yes, DDCMP does its own block delimiting on both sync and async lines, basically the same way for both. It recognizes the header by byte patterns plus good CRC, and the payload framing is controlled by the payload byte count that's mentioned in the header.
It's all in the spec. Take a look, it's a very clear and very simple document.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Wednesday, January 04, 2012 6:46 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Hecnet and DDCMP
On 2012-01-04 23.15, Paul_Koning at Dell.com wrote:
I assume there has to be a bit more to it, because DDCMP is a packet based protocol
(not a stream protocol as TCP is) and the higher layers rely on that. So there
presumably is some form of framing in the emulated data stream to indicate where the
packet boundaries are.
Paul, how does this work when you have DDCMP over an asynch serial line?
There are no frames there. It is just a stream of bytes at the physical
layer, exactly the same as TCP for example. Yet, DDCMP talks over that
too... DDCMP must be implementing the blocking/deblocking on its own in
that case.
Johnny
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Rob Jarratt
Sent: Wednesday, January 04, 2012 5:11 PM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
All I do in SIMH is to take the data bytes each end wants to send to the other end and send them over a socket, so I don't get involved with DDCMP itself. Both ends have to be SIMH for this to work. I don't do anything at the actual hardware level, although that would be nice. I think you can get synchronous serial cards for the PC but they are quite expensive.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 03 January 2012 21:18
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
DMC-11 speaks DDCMP V3.1 (give or take some bugs in the "high speed"
version). But that's sync only. Depending on what you want to talk
to, a
DMC
(or its relatives DMR-11, DMP-11, or DMV-11) may not help; if the
other
end
speaks DDCMP over an async link (UART) then it won't work because the
character framing doesn't match.
That said, I wonder what it means to emulate a DMC-11. You could have
it speak DDCMP over a UART, or something else entirely. If the former
it
would
talk to another DDCMP node; if the latter it would not but it would
still
work
for tying one emulated DMC-11 to another.
If you want DDCMP, one approach is to get a copy of the spec, and
implement
what it says. That works; it is how I implemented DDCMP support for
RSTS
V10
(based on an earlier version based on V9.6). The protocol is quite
simple
and
the spec is well enough written that, if you do what it says, the
result
WILL
interoperate with hardware such as the DMR-11. The only tricky one is
the
DMC-11 because it has some undocumented bugs; the main one I remember
is that the high speed version can't handle back to back packets. I
wish
I could
contribute the code I wrote but I can't, for various reasons one of
them
is that
it's a RSTS device driver and written in 100% assembly language.
It would not be hard to do a version for other platforms; I once
looked at
a
Linux terminal protocol handler (forgot what that is called) that
could
hook
into DECnet/Linux. Didn't get far enough on that, though.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Mark Abene
Sent: Sunday, January 01, 2012 6:06 PM
To: hecnet at update.uu.se
Subject: Re: [HECnet] Hecnet and DDCMP
Jarratt, did you make this publicly available on the SIMH list? It
would
be great
to have a DMC11 device emulated, since I insist on running RSTS/E v8
(for historical reasons... it was the last real RSTS before "the pollution").
RSTS/E v8
doesn't have ethernet support, so the only way I could have DECnet is
via
a
(previously unemulated)
DMC11 interface. Does yours work well?
-Mark
On Sun, Jan 1, 2012 at 3:23 AM, Jarratt RMA
<robert.jarratt at ntlworld.com>
wrote:
Working with a friend, I have written a SIMH emulation of the DMC11
device, so you can do this with SIMH. It tunnels the bytes sent
to/from the device over a socket. We have used the SIMH emulation to
connect my friend to HECnet over a (simulated) DMC11.
The bit I am not entirely sure about is to what extent this is using
DDCMP as I don't have a full understanding of DDCMP.
Regards
Rob
On 31 December 2011 18:46, The Presence<tpresence at hotmail.com>
wrote:
Hey guys,
Has anyone worked out a mechanism to connect a node to hecnet using
DDCMP?
Perhaps some tunneling technology over IP, or virtualized serial?
Kevin
On 2012-01-04 23.31, Steve Davidson wrote:
Have we decided on what the circuit costs should be set to for the
Multinet circuits? I just did:
NCP TELL MIM SHOW KNOW AREAS
and discovered that MIM's view of the world has changed. From what I can
tell it is due to changes is circuit costs. I have made no changes at my
end. I was waiting for consensus before making any changes.
-Steve
I don't know if a general consensus was reached, but I agree with the idea expressed. When you have both the bridge, and Multinet DECnet tunneled, make the costs for the Multinet circuits lower.
Yes, the changes made by some have had effect on how the routing from MIMs point of view looks. And I think it's an improvement. A few destinations farther away that I tested against were noticeable faster now.
Johnny
On 2012-01-04 23.15, Paul_Koning at Dell.com wrote:
I assume there has to be a bit more to it, because DDCMP is a packet based protocol
(not a stream protocol as TCP is) and the higher layers rely on that. So there
presumably is some form of framing in the emulated data stream to indicate where the
packet boundaries are.
Paul, how does this work when you have DDCMP over an asynch serial line? There are no frames there. It is just a stream of bytes at the physical layer, exactly the same as TCP for example. Yet, DDCMP talks over that too... DDCMP must be implementing the blocking/deblocking on its own in that case.
Johnny
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Rob Jarratt
Sent: Wednesday, January 04, 2012 5:11 PM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
All I do in SIMH is to take the data bytes each end wants to send to the other end and send them over a socket, so I don't get involved with DDCMP itself. Both ends have to be SIMH for this to work. I don't do anything at the actual hardware level, although that would be nice. I think you can get synchronous serial cards for the PC but they are quite expensive.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 03 January 2012 21:18
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
DMC-11 speaks DDCMP V3.1 (give or take some bugs in the "high speed"
version). But that's sync only. Depending on what you want to talk
to, a
DMC
(or its relatives DMR-11, DMP-11, or DMV-11) may not help; if the
other
end
speaks DDCMP over an async link (UART) then it won't work because the
character framing doesn't match.
That said, I wonder what it means to emulate a DMC-11. You could have
it speak DDCMP over a UART, or something else entirely. If the former
it
would
talk to another DDCMP node; if the latter it would not but it would
still
work
for tying one emulated DMC-11 to another.
If you want DDCMP, one approach is to get a copy of the spec, and
implement
what it says. That works; it is how I implemented DDCMP support for
RSTS
V10
(based on an earlier version based on V9.6). The protocol is quite
simple
and
the spec is well enough written that, if you do what it says, the
result
WILL
interoperate with hardware such as the DMR-11. The only tricky one is
the
DMC-11 because it has some undocumented bugs; the main one I remember
is that the high speed version can't handle back to back packets. I
wish
I could
contribute the code I wrote but I can't, for various reasons one of
them
is that
it's a RSTS device driver and written in 100% assembly language.
It would not be hard to do a version for other platforms; I once
looked at
a
Linux terminal protocol handler (forgot what that is called) that
could
hook
into DECnet/Linux. Didn't get far enough on that, though.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Mark Abene
Sent: Sunday, January 01, 2012 6:06 PM
To: hecnet at update.uu.se
Subject: Re: [HECnet] Hecnet and DDCMP
Jarratt, did you make this publicly available on the SIMH list? It
would
be great
to have a DMC11 device emulated, since I insist on running RSTS/E v8
(for historical reasons... it was the last real RSTS before "the pollution").
RSTS/E v8
doesn't have ethernet support, so the only way I could have DECnet is
via
a
(previously unemulated)
DMC11 interface. Does yours work well?
-Mark
On Sun, Jan 1, 2012 at 3:23 AM, Jarratt RMA
<robert.jarratt at ntlworld.com>
wrote:
Working with a friend, I have written a SIMH emulation of the DMC11
device, so you can do this with SIMH. It tunnels the bytes sent
to/from the device over a socket. We have used the SIMH emulation to
connect my friend to HECnet over a (simulated) DMC11.
The bit I am not entirely sure about is to what extent this is using
DDCMP as I don't have a full understanding of DDCMP.
Regards
Rob
On 31 December 2011 18:46, The Presence<tpresence at hotmail.com>
wrote:
Hey guys,
Has anyone worked out a mechanism to connect a node to hecnet using
DDCMP?
Perhaps some tunneling technology over IP, or virtualized serial?
Kevin
Yes, you are right, I do add a 2-byte length to the start of each buffer
that I send so that the other end can reassemble the buffer. Sorry, I did
say this in an earlier draft of the email, but decided to leave it out to
emphasise the simplicity of the implementation.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 04 January 2012 22:15
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
I assume there has to be a bit more to it, because DDCMP is a packet based
protocol (not a stream protocol as TCP is) and the higher layers rely on
that.
So there presumably is some form of framing in the emulated data stream to
indicate where the packet boundaries are.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Rob Jarratt
Sent: Wednesday, January 04, 2012 5:11 PM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
All I do in SIMH is to take the data bytes each end wants to send to the
other
end and send them over a socket, so I don't get involved with DDCMP
itself.
Both ends have to be SIMH for this to work. I don't do anything at the
actual
hardware level, although that would be nice. I think you can get
synchronous
serial cards for the PC but they are quite expensive.
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 03 January 2012 21:18
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Hecnet and DDCMP
DMC-11 speaks DDCMP V3.1 (give or take some bugs in the "high speed"
version). But that's sync only. Depending on what you want to talk
to, a
DMC
(or its relatives DMR-11, DMP-11, or DMV-11) may not help; if the
other
end
speaks DDCMP over an async link (UART) then it won't work because the
character framing doesn't match.
That said, I wonder what it means to emulate a DMC-11. You could have
it speak DDCMP over a UART, or something else entirely. If the former
it
would
talk to another DDCMP node; if the latter it would not but it would
still
work
for tying one emulated DMC-11 to another.
If you want DDCMP, one approach is to get a copy of the spec, and
implement
what it says. That works; it is how I implemented DDCMP support for
RSTS
V10
(based on an earlier version based on V9.6). The protocol is quite
simple
and
the spec is well enough written that, if you do what it says, the
result
WILL
interoperate with hardware such as the DMR-11. The only tricky one is
the
DMC-11 because it has some undocumented bugs; the main one I
remember
is that the high speed version can't handle back to back packets. I
wish
I could
contribute the code I wrote but I can't, for various reasons one of
them
is that
it's a RSTS device driver and written in 100% assembly language.
It would not be hard to do a version for other platforms; I once
looked at
a
Linux terminal protocol handler (forgot what that is called) that
could
hook
into DECnet/Linux. Didn't get far enough on that, though.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Mark Abene
Sent: Sunday, January 01, 2012 6:06 PM
To: hecnet at update.uu.se
Subject: Re: [HECnet] Hecnet and DDCMP
Jarratt, did you make this publicly available on the SIMH list? It
would
be great
to have a DMC11 device emulated, since I insist on running RSTS/E v8
(for historical reasons... it was the last real RSTS before "the
pollution").
RSTS/E v8
doesn't have ethernet support, so the only way I could have DECnet is
via
a
(previously unemulated)
DMC11 interface. Does yours work well?
-Mark
On Sun, Jan 1, 2012 at 3:23 AM, Jarratt RMA
<robert.jarratt at ntlworld.com>
wrote:
Working with a friend, I have written a SIMH emulation of the DMC11
device, so you can do this with SIMH. It tunnels the bytes sent
to/from the device over a socket. We have used the SIMH emulation to
connect my friend to HECnet over a (simulated) DMC11.
The bit I am not entirely sure about is to what extent this is using
DDCMP as I don't have a full understanding of DDCMP.
Regards
Rob
On 31 December 2011 18:46, The Presence <tpresence at hotmail.com>
wrote:
Hey guys,
Has anyone worked out a mechanism to connect a node to hecnet using
DDCMP?
Perhaps some tunneling technology over IP, or virtualized serial?
Kevin
There is a possibility to use a real system however, if a client was written that would read input from the socket and throw it out of the serial port on physical hardware? As long as the original data integrity is maintained this should work as long as timing isn't an issue, correct? You basically created a virtual driver that behaved as a serial adapter?
Was this done over TCP/IP or DecNET, or LAT or something else?
For synchronous comms (assuming DMC-11 RS232-C physical) you would need to use a 25 pin connector to wire it as it requires pins 15, 17 and 24 for the clock signal in addition to the standard async pins. It would just be a matter of putting in a microcontroller such as the launchpad or arduino to handle the synchronous communications, and then pass it back out async. Yes this would probably be very messy and perhaps the wrong way to go.
Regardless, I would love to see what you have done to get this working SIMH->SIMH.
Thanks heaps,
Kevin
> From: robert.jarratt at ntlworld.com
> To: hecnet at Update.UU.SE
> Subject: RE: [HECnet] Hecnet and DDCMP
> Date: Wed, 4 Jan 2012 22:10:47 +0000
>
> All I do in SIMH is to take the data bytes each end wants to send to the
> other end and send them over a socket, so I don't get involved with DDCMP
> itself. Both ends have to be SIMH for this to work. I don't do anything at
> the actual hardware level, although that would be nice. I think you can get
> synchronous serial cards for the PC but they are quite expensive.
>
> Regards
>
> Rob
>
