13 Dec
2021
13 Dec
'21
12:25 a.m.
I don't get it at all.
A DUP is a synchronous serial interface.
That means it sends and receives bytes. Nothing more, nothing less.
If you want to simulate it, you should be sending bytes verbatim, and
receive them verbatim. Any framing or other trickery should not be done,
because a DUP does not do that.
DDCMP does framing, which is well documented. Which means if you
simulate a KMC-DUP combo, you should just run DDCMP on the stream of
bytes. Your DDCMP implementation will catch and do the framing as expected.
And if you connect that with a DUP that just do DDCMP in software, it
will be getting the same stream of bytes, and will manage the framing in
software.
Using TCP for this should be extremely simple and straight forward.
Using UDP is not something I would ever recommend here. But if you
insist, maybe you could just pretend the data is a chunk of bytes to be
fed in and processed the same as if it had been TCP.
And it's the same story if you have a DZ or KMC-DZ.
Johnny
On 2021-12-12 22:27, Paul Koning wrote:
So... if DUP-only mode using TMXR framed transmission
which throws in a
size field on TCP, that would imply UDP mode should be used instead. ?Right?
paul
--
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
On Dec 12, 2021, at 1:46 PM, Mark Pizzolato -
Info Comm
<Mark at infocomm.com <mailto:Mark at infocomm.com>> wrote:
The byte count is absolutely needed in TCP mode since the byte count
describes the packet boundaries on the wire.? UDP mode is already
packets hence the insertion of the packet length preceding the data so
the next layer doesn?t (in the device simulation) doesn?t have to be
aware of TCP or UDP.
*From:*owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>
<owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE>>*On
Behalf Of*Paul Koning
*Sent:*Sunday, December 12, 2021 10:42 AM
*To:*hecnet at update.uu.se <mailto:hecnet at update.uu.se>
*Subject:*Re: [HECnet] native Dup sync line revisited --> preliminary
tests reveals problems
You mean DUP-alone? ?KMC-DUP is compatible with DMC, right? ?And that
sends (in TCP mode) the frames as-is, no byte count since none is needed.
paul
On Dec 12, 2021, at 1:37 PM, Mark Pizzolato - Info Comm
<Mark at infocomm.com <mailto:Mark at infocomm.com>> wrote:
The functioning DUP simulation only sends packets.? If the
connection is TCP, then a 2 byte packet size is stuffed ahead of
the packet data on transmit and the receiving side strips this
from the data presented to the simulated system.? In UDP mode, the
UDP packet size is stuffed into the beginning of the packet buffer
and that size is then also stripped just like the TCP case.
The problems that Reindert is seeing are probably related to
timing of byte delivery into the simulation or timing of
successive packets being delivered which may possibly overrun
buffer space in the simulated OS.
*From:*owner-hecnet at Update.UU.SE
<mailto:owner-hecnet at Update.UU.SE><owner-hecnet at Update.UU.SE
<mailto:owner-hecnet at Update.UU.SE>>*On Behalf Of*Paul Koning
*Sent:*Sunday, December 12, 2021 10:29 AM
*To:*hecnet at update.uu.se <mailto:hecnet at update.uu.se>
*Subject:*Re: [HECnet] native Dup sync line revisited -->
preliminary tests reveals problems
On Dec 11, 2021, at 7:41 PM, R. Voorhorst
<R.Voorhorst at swabhawat.com <mailto:R.Voorhorst at swabhawat.com>>
wrote:
L.S.
This is the follow-up from the Dup-without-Kdp in character
mode discussion somewhat earlier, where I stated it was not
supported per the specifications in Simh comments and Mark P
had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node
Rsx-11M+ test set, used for specific Decnet testing for
Phase-I to IV. These triple nodes were setup for using every
possible device for Decnet communications, amongst them the
native (non-kdp) Dup. This one in multipoint mode is character
based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode,
this would establish sufficient proof for a well-functioning
character based synchronous line.
Yes, if you use TCP mode. ?It's not likely to work in UDP mode
because then the DMC emulation expects to get a full DDCMP frame
in a single UDP packet. ?But in TCP mode it just picks apart the
byte stream.
When the Dup line is interfaced to a Dmc line, the test
reveals flapping line behaviour: line up -? circuit fault ?
line down; when trying to transfer data an immediate circuit
fault appears.
When the Dup is interfaced to another Dup, there is packet
exchange so basically it should be able to work. However,
although there are no problems with the lower length (8)
signaling packets, the moment 22 char packets are transferred,
the receiver complains about bad header as well as bad data
crc checksums, so the packets are somewhat mangled. ?It
prohibits to start Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF
01 28 04 01 40 02 02 00 .........(..@ <mailto:..@>...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D
46?????????????????????????????? .....F
DBG(10561953465)> DUP RCV:? rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet? len: 22
DBG(10561953465)> DUP PKT:*Data Message, Count: 12, Num: 1,
Flags: SQ, Resp: 0,_HDRCRC: BAD, DATACRC: BAD_*
...
Per Mark P?s comment that some kind of filtering takes place
in non-kdp dup mode, that might indicate that the source of
the problems could be located in that corner.
That behaviour needs to be examined.
I wonder what kind of filtering that might be. ?The header ?looks
completely normal for a DDCMP data frame, it indicates a data
length of 12 bytes which matches what you see in that packet. ?12
would be the expected length of a Routing Init message, normally
the first data packet sent after DDCMP startup is complete. ? Then
again, its contents make no sense as an Init message. ? Sending
node 1.40, does that seem right? ?But the "tiiinfo" (node type
etc.) is 0x40 which isn't valid. ?Nor is the routing version
(0.0.15) or the hello timer value (0).
Could it be that one side is set in TELNET mode while the other is
not? ?The settings must match or 0xff bytes are mishandled.
paul