Feature request: support for NS-to-PUP host lookup, XIP type 6

[nbriggs]

In addition to XIP types 1 (routing), 2 (echo), ... 5 (spp) the Medley code uses 6 (PUP lookup).

A PUP lookup XIP looks like a Packet Exchange XIP, except for having XIP type 6. A normal packet exchange ID is used. It is broadcast to well-known socket 9. The packet exchange protocol-specific type field is set to request (1), response (2), or negative (3). Negative responses are ignored. A request type PUP lookup contains the 48-bit XNS host address of the device that is to be looked up as the payload. A response type PUP lookup contains in one 16-bit word (big-endian) the PUP network number (high byte) and the PUP host number (low byte)"as stored in the gateway's database." A zero low byte is invalid unless the address being looked up was the broadcast NS address. The PUP network number should be specifiable, but will generally be ignored because of the confusion about machines that had interfaces on more than one PUP network.

I might be able to find time to implement this...

[devhawala]

ok, this explains the strange packets coming at Medley startup and sometimes later...

I can add some mapping from 48-bit machine-id to 16 bit PUP network address somewhere (machines.cfg or Clearinghouse configuration files for servers and workstations) to feed a new responder for type 6 broadcast packets.

Do you have some PUP server implemention in your network? Or do plan to use the IFS implementation from the livingcomputermuseum-github-site?

At least in the later case, some new network adapter will be needed somewhere (Maiko, NetHub, IFS) for allowing Maiko to exchange PUP packets with the PUP server?

[nbriggs]

Medley can speak to other instances of itself with PUP packets (encapsulated for the 10 Mb ethernet, I think, rather than the raw PUPs as would be sent on the 3 Mb wire) but this would be a pretty low priority item since there's no other PUP-speaking client that would use this.

[nbriggs]

If you were to do this, I think machines.cfg would be the appropriate place to note the additional property, something like PUP.HostAddress = ... in a machine's section. It's unfortunate that # is taken for comments, since the traditional notation for a PUP address is 131#5# where the network (131) and host (5) numbers are octal.

[devhawala]

The PUP address format is not a problem, as only lines beginning with a # (after trimming) are interpreted as comments...

The just uploaded a new version of Dodo allows to add a line

+ pup.hostAddress = <net>#<adr>#

to a machine definition in the machines-cfg file to define its PUP address.

The new "NStoPupHostLookup" service is started with the Clearinghouse/Authentication services. If a queried 48-bit address has a valid "pup.hostAddress" definition (net and adr are octal in the decimal range 0..255), the service will answer with a "response"-type packet, else with a "negative"-type packet.

An interesting positive side-effect of Dodo providing the PUP-addesses is that the Medley-UI is usable immediately after starting the system: until now, it took some time before the caret started blinking and context-menus could be opened. It seems that system waits synchronously for the response packets, so the missing responses to the 4 broadcasts for PUP-address slowed down the system startup...

Anyway, now Interlisp-D/Medley starts sending ethertype 0x200 packets ("XEROX PUP" according to IEEE 802 Numbers), so far without getting responses of course.

[nbriggs]

Nice! I notice one problem, though — it’s not copying the XIP exchange id from the request packet to the response packet. The NS-to-PUP lookups are really PacketExchange packets, and have that structure and follow that protocol, except for the PEX type being the NS-to-PUP lookup type.

— Nick

On Nov 27, 2022, at 9:38 AM, devhawala @.***> wrote:

The PUP address format is not a problem, as only lines beginning with a # (after trimming) are interpreted as comments...

The just uploaded a new version of Dodo allows to add a line

• pup.hostAddress = ## to a machine definition in the machines-cfg file to define its PUP address.

The new "NStoPupHostLookup" service is started with the Clearinghouse/Authentication services. If a queried 48-bit address has a valid "pup.hostAddress" definition (net and adr are octal in the decimal range 0..255), the service will answer with a "response"-type packet, else with a "negative"-type packet.

An interesting positive side-effect of Dodo providing the PUP-addesses is that the Medley-UI is usable immediately after starting the system: until now, it took some time before the caret started blinking and context-menus could be opened. It seems that system waits synchronously for the response packets, so the missing responses to the 4 broadcasts for PUP-address slowed down the system startup...

Anyway, now Interlisp-D/Medley starts sending ethertype 0x200 packets ("XEROX PUP" according to IEEE 802 Numbers https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml), so far without getting responses of course.

— Reply to this email directly, view it on GitHub https://github.com/devhawala/dodo/issues/17#issuecomment-1328302216, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6DAWLQ5GYFLSXVQA36HFTWKOMDBANCNFSM6AAAAAARWNK6RE. You are receiving this because you authored the thread.

[devhawala]

should be fixed with the new upload: the identification in the response is copied form the request packet

[nbriggs]

Perfect! Thanks.

On Nov 28, 2022, at 8:54 AM, devhawala @.***> wrote:

should be fixed with the new upload: the identification in the response is copied form the request packet

— Reply to this email directly, view it on GitHub https://github.com/devhawala/dodo/issues/17#issuecomment-1329429320, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6DAWMGGPBHZWAUVQD65PDWKTPVXANCNFSM6AAAAAARWNK6RE. You are receiving this because you authored the thread.