DXSpider PC Packet Cluster Protocol - Revision history

WI3W: Add credit to WI3W for initial compilation.

2025-04-02T01:07:00Z

Add credit to WI3W for initial compilation.

← Older revision		Revision as of 01:07, 2 April 2025
Line 289:		Line 289:

	Connecting to an old style PC protocol node is much more verbose but the PC18 -> PC20 -> PC22 pattern is the same. It just has a big flurry of PC19/PC17 records in between these three markers. The principle is the same.		Connecting to an old style PC protocol node is much more verbose but the PC18 -> PC20 -> PC22 pattern is the same. It just has a big flurry of PC19/PC17 records in between these three markers. The principle is the same.


			Information initially compiled from dxcluster.org, DXSpider Support list serv, and DXSpider Technical list serv by Chris, WI3W.

WI3W: Formatting

2025-03-13T02:38:49Z

Formatting

← Older revision		Revision as of 02:38, 13 March 2025
Line 245:		Line 245:
	There is no "initial handshake" as such for nodes at this level. You are not a node until you have successfully logged in as a known entity to a node. Only at that point does PC protocol happen - '''if you are defined as a node with that callsign''' - on the node that you are attempting to connect to. Otherwise you will be treated as a user, given the contents of any MOTD file and sent a user prompt.		There is no "initial handshake" as such for nodes at this level. You are not a node until you have successfully logged in as a known entity to a node. Only at that point does PC protocol happen - '''if you are defined as a node with that callsign''' - on the node that you are attempting to connect to. Otherwise you will be treated as a user, given the contents of any MOTD file and sent a user prompt.

	So if one connects to a PC92 capable node; you have successfully logged with user (+password if required); that username is a callsign that is ~~recognised~~ as a node by the receiving node; you are not locked out there (the default for some random node callsign) - then this happens (GB7TLH-2 connecting to GB7DJK) as shown from the receiving node's (GB7DJK) point of view:		So if one connects to a PC92 capable node; you have successfully logged with user (+password if required); that username is a callsign that is recognized as a node by the receiving node; you are not locked out there (the default for some random node callsign) - then this happens (GB7TLH-2 connecting to GB7DJK) as shown from the receiving node's (GB7DJK) point of view:

	11:31:10 (chan) <- A GB7TLH-2 telnet		11:31:10 (chan) <- A GB7TLH-2 telnet
Line 282:		Line 282:

	<span style="color:#008000">11:31:13 (chan) -> D GB7TLH-2 PC51^GB7TLH-2^GB7DJK^0^</span>		<span style="color:#008000">11:31:13 (chan) -> D GB7TLH-2 PC51^GB7TLH-2^GB7DJK^0^</span>
	~~Actual data transfer data <span style="color:#008000">green</span> = GB7DJK (receiving node) <span style="color:#ff0000">red</span> = GB7TLH-2 (connecting node).~~

	Actual data transfer data <span style="color:#008000">green</span> = GB7DJK (receiving node) <span style="color:#ff0000">red</span> = GB7TLH-2 (connecting node).		Actual data transfer data <span style="color:#008000">green</span> = GB7DJK (receiving node) <span style="color:#ff0000">red</span> = GB7TLH-2 (connecting node).

WI3W: Formatting

2025-03-13T02:34:27Z

Formatting

← Older revision		Revision as of 02:34, 13 March 2025
Line 238:		Line 238:

	Note that for backwards compatibility all chat <text> sections have a serial number #1->#999 + a space added to it. The first chat message sent after restart should be a random no in that range. This is designed to defeat any de-duping on announces.		Note that for backwards compatibility all chat <text> sections have a serial number #1->#999 + a space added to it. The first chat message sent after restart should be a random no in that range. This is designed to defeat any de-duping on announces.

WI3W: Formatting

2025-03-13T02:33:05Z

Formatting

← Older revision		Revision as of 02:33, 13 March 2025
Line 239:		Line 239:
	Note that for backwards compatibility all chat <text> sections have a serial number #1->#999 + a space added to it. The first chat message sent after restart should be a random no in that range. This is designed to defeat any de-duping on announces.		Note that for backwards compatibility all chat <text> sections have a serial number #1->#999 + a space added to it. The first chat message sent after restart should be a random no in that range. This is designed to defeat any de-duping on announces.

	'''Initial Connection Process'''There is no "initial handshake" as such for nodes at this level. You are not a node until you have successfully logged in as a known entity to a node. Only at that point does PC protocol happen - '''if you are defined as a node with that callsign''' - on the node that you are attempting to connect to. Otherwise you will be treated as a user, given the contents of any MOTD file and sent a user prompt.
			'''Initial Connection Process'''

			There is no "initial handshake" as such for nodes at this level. You are not a node until you have successfully logged in as a known entity to a node. Only at that point does PC protocol happen - '''if you are defined as a node with that callsign''' - on the node that you are attempting to connect to. Otherwise you will be treated as a user, given the contents of any MOTD file and sent a user prompt.

	So if one connects to a PC92 capable node; you have successfully logged with user (+password if required); that username is a callsign that is recognised as a node by the receiving node; you are not locked out there (the default for some random node callsign) - then this happens (GB7TLH-2 connecting to GB7DJK) as shown from the receiving node's (GB7DJK) point of view:		So if one connects to a PC92 capable node; you have successfully logged with user (+password if required); that username is a callsign that is recognised as a node by the receiving node; you are not locked out there (the default for some random node callsign) - then this happens (GB7TLH-2 connecting to GB7DJK) as shown from the receiving node's (GB7DJK) point of view:
Line 278:		Line 281:

	<span style="color:#008000">11:31:13 (chan) -> D GB7TLH-2 PC51^GB7TLH-2^GB7DJK^0^</span>		<span style="color:#008000">11:31:13 (chan) -> D GB7TLH-2 PC51^GB7TLH-2^GB7DJK^0^</span>
			Actual data transfer data <span style="color:#008000">green</span> = GB7DJK (receiving node) <span style="color:#ff0000">red</span> = GB7TLH-2 (connecting node).

	Actual data transfer data <span style="color:#008000">green</span> = GB7DJK (receiving node) <span style="color:#ff0000">red</span> = GB7TLH-2 (connecting node).		Actual data transfer data <span style="color:#008000">green</span> = GB7DJK (receiving node) <span style="color:#ff0000">red</span> = GB7TLH-2 (connecting node).

WI3W: Added Dirk's commentary about the initial node connection process.

2025-03-13T02:31:47Z

Added Dirk's commentary about the initial node connection process.

← Older revision		Revision as of 02:31, 13 March 2025
Line 238:		Line 238:

	Note that for backwards compatibility all chat <text> sections have a serial number #1->#999 + a space added to it. The first chat message sent after restart should be a random no in that range. This is designed to defeat any de-duping on announces.		Note that for backwards compatibility all chat <text> sections have a serial number #1->#999 + a space added to it. The first chat message sent after restart should be a random no in that range. This is designed to defeat any de-duping on announces.

			'''Initial Connection Process'''There is no "initial handshake" as such for nodes at this level. You are not a node until you have successfully logged in as a known entity to a node. Only at that point does PC protocol happen - '''if you are defined as a node with that callsign''' - on the node that you are attempting to connect to. Otherwise you will be treated as a user, given the contents of any MOTD file and sent a user prompt.

			So if one connects to a PC92 capable node; you have successfully logged with user (+password if required); that username is a callsign that is recognised as a node by the receiving node; you are not locked out there (the default for some random node callsign) - then this happens (GB7TLH-2 connecting to GB7DJK) as shown from the receiving node's (GB7DJK) point of view:

			11:31:10 (chan) <- A GB7TLH-2 telnet

			11:31:10 (chan) -> B GB7TLH-2 0

			11:31:10 (chan) -> E GB7TLH-2 0

			<span style="color:#008000">11:31:10 (chan) -> D GB7TLH-2 PC18^DXSpider Version: 1.57 Build: 569 Git: test/83fc0019[r] pc9x^5457^</span>

			11:31:10 (state) GB7TLH-2 channel func state 0 -> init

			<span style="color:#ff0000">11:31:10 (chan) <- I GB7TLH-2 PC92^GB7TLH-2^41469^A^^5GB7DJK:2001,bc8,3b8c,200,,2^H99^</span>

			11:31:10 (state) GB7TLH-2 channel func state init -> init92

			11:31:10 (*) DXPROT: Do pc9x set on GB7TLH-2

			<span style="color:#ff0000">11:31:10 (chan) <- I GB7TLH-2 PC92^GB7TLH-2^41469.01^K^5GB7TLH-2:5457:536^4^1^H99^</span>

			<span style="color:#ff0000">11:31:10 (chan) <- I GB7TLH-2 PC20^</span>

			11:31:10 (*) GB7TLH-2 send_local_config: doing pc9x

			<span style="color:#008000">11:31:10 (chan) -> D GB7TLH-2 PC92^GB7DJK^41469^A^^5GB7TLH-2:2a01,4f8,1c1b,c95c,,1^H99^</span>

			<span style="color:#008000">11:31:10 (chan) -> D GB7TLH-2 PC92^GB7DJK^41469.01^K^5GB7DJK:5457:569^25^65^163.172.11.79^test/83fc0019[r]^H99^</span>

			<span style="color:#008000">11:31:10 (chan) -> D GB7TLH-2 PC22^</span>

			11:31:10 (state) GB7TLH-2 channel func state init92 -> normal

			shortly followed by:

			<span style="color:#ff0000">11:31:13 (chan) <- I GB7TLH-2 PC51^GB7DJK^GB7TLH-2^1^</span>

			<span style="color:#008000">11:31:13 (chan) -> D GB7TLH-2 PC51^GB7TLH-2^GB7DJK^0^</span>

			Actual data transfer data <span style="color:#008000">green</span> = GB7DJK (receiving node) <span style="color:#ff0000">red</span> = GB7TLH-2 (connecting node).

			The stuff in black is normal logging on the receiving node (GB7DJK) - and not passed across this connection.

			Connecting to an old style PC protocol node is much more verbose but the PC18 -> PC20 -> PC22 pattern is the same. It just has a big flurry of PC19/PC17 records in between these three markers. The principle is the same.

WI3W: Updated protocols found/not found in the source code.

2025-03-13T01:48:05Z

Updated protocols found/not found in the source code.

← Older revision		Revision as of 01:48, 13 March 2025
Line 11:		Line 11:
	\| Announcement \|\| PC12^from-user^route-to-node^msg^sysop-flg^origin-node^wx-flg^hops^~		\| Announcement \|\| PC12^from-user^route-to-node^msg^sysop-flg^origin-node^wx-flg^hops^~
	\|-		\|-
	\| Stn into ~~CONF~~ \|\| PC13^user^hops^		\| Stn into CONF¹ \|\| PC13^user^hops^
	\|-		\|-
	\| Stn out of ~~CONF~~ \|\| PC14^user^hops^		\| Stn out of CONF¹ \|\| PC14^user^hops^
	\|-		\|-
	\| Conference Mode \|\| PC15^from-user^msg^hops^~		\| Conference Mode \|\| PC15^from-user^msg^hops^~
Line 87:		Line 87:
	\| Ping \|\| PC51^route-to-node^route-from-node^ping-flag^		\| Ping \|\| PC51^route-to-node^route-from-node^ping-flag^
	\|-		\|-
	\| WCY Info \|\| PC73^date^hour^SFI^A^K^~~ExpK~~^R^SA^GMF^~~Aurora~~^logger^origin-node^hops^		\| WCY Info \|\| PC73^date^hour^SFI^A^K^expK^R^SA^GMF^aurora^logger^origin-node^hops^
			\|-
			\|Unknown²
			\|PC75
			\|-
			\|CLX Remote CMD Send
			\|PC84^to-node^from-node^call^msg^~
			\|-
			\|CLX Remote CMD Reply
			\|PC85^to-node^from-node^call^msg^~
	\|}		\|}

			¹ Not found in DXSpider source code.

			² Found in DXProtHandle.pm - Line 1705: #dunno but route it

	{\| class="wikitable"		{\| class="wikitable"
Line 191:		Line 202:

	'''PC93 - Talk/Announce/WX'''		'''PC93 - Talk/Announce/WX'''



	PC93^<node call>^<timestamp>^<to>^<from>^<via>^<text>[^<onode>][^<IPaddr>]^H99		PC93^<node call>^<timestamp>^<to>^<from>^<via>^<text>[^<onode>][^<IPaddr>]^H99

WI3W: Tidied up some formatting that did not carry over from the original document.

2025-03-12T00:11:40Z

Tidied up some formatting that did not carry over from the original document.

← Older revision		Revision as of 00:11, 12 March 2025
Line 99:		Line 99:
	\| DX Info \|\| PC61^DXfreq^DXcall^date^time^comment-txt^user-rprt^origin-node^user-ip^hops^~ \|\| P61 is a replacement for PC11 originating with Lee Sawkins, VE7CC. PC61 differs by allowing several significant digits after the frequency decimal. All other fields are the same, except for an added originating user IP address. The user IP can be IPv4 or IPv6.		\| DX Info \|\| PC61^DXfreq^DXcall^date^time^comment-txt^user-rprt^origin-node^user-ip^hops^~ \|\| P61 is a replacement for PC11 originating with Lee Sawkins, VE7CC. PC61 differs by allowing several significant digits after the frequency decimal. All other fields are the same, except for an added originating user IP address. The user IP can be IPv4 or IPv6.
	\|-		\|-
	\| General Info \|\| PC9x^<node call>^<seconds since last midnight>^ \|\| <seconds since last midnight> is the number of seconds since the beginning of "today" UTC. It MUST be unique and increase with each sentence. It can therefore be a decimal number. The idea being that if the next sentence is sent in the same second as the last one, then you append (for instance) '.01' on the end. If there is an other one: .02 etc. But you add any number of decimal points (eg '.1' or '.001') you like. Look at gen_pc9x_t in DXProtHandle.pm for an example.		\| General Info \|\| PC9x^<node call>^<seconds since last midnight>^... \|\| <seconds since last midnight> is the number of seconds since the beginning of "today" UTC. It MUST be unique and increase with each sentence. It can therefore be a decimal number. The idea being that if the next sentence is sent in the same second as the last one, then you append (for instance) '.01' on the end. If there is an other one: .02 etc. But you add any number of decimal points (eg '.1' or '.001') you like. Look at gen_pc9x_t in DXProtHandle.pm for an example.

	At midnight, they all go back to 0.		At midnight, they all go back to 0.
Line 133:		Line 133:
	'K' keep alive records		'K' keep alive records

	~~5GB7TLH:5457 ---.~~

	\|		5GB7TLH:5457

	5 is a bit map which is made up like this:-		5 is a bit map which is made up like this:-
Line 155:		Line 154:
	GB7TLH is the callsign		GB7TLH is the callsign

	<nowiki>:</nowiki>5457 is the version number, other fields may be tacked on		<nowiki>:</nowiki>5457 is the version number, other fields may be tacked on (see K record below)

	The first slot after the 'C', 'A' or 'D', is always reserved for the node call. This slot may be empty (as in ...^A^^1G1TLH^... as opposed to ..^A^5GB7TLH^1G1TLH^..) if the node is the same as the node call after PC92. Any software must be able to cope with this empty slot.		The first slot after the 'C', 'A' or 'D', is always reserved for the node call. This slot may be empty (as in ...^A^^1G1TLH^... as opposed to ..^A^5GB7TLH^1G1TLH^..) if the node is the same as the node call after PC92. Any software must be able to cope with this empty slot.
			The remaining payload...

	The remaining payload...		The remaining payload...
Line 166:		Line 166:

	<nowiki>*</nowiki>Note: the IP address may not always be present at this time.		<nowiki>*</nowiki>Note: the IP address may not always be present at this time.


	H99 - hopcount		H99 - hopcount
Line 177:		Line 178:

	The principle being used here is similar to protocols like OSPF. A node only sends records that either come from it or PC nodes that it is "responsible" for. Nodes do not splurge out their local view of the network to cause even more confusion...		The principle being used here is similar to protocols like OSPF. A node only sends records that either come from it or PC nodes that it is "responsible" for. Nodes do not splurge out their local view of the network to cause even more confusion...


	'K' Record Examples - Keep Alive		'K' Record Examples - Keep Alive

	GB7DJK PC92^GB7TLH^82234^K^5GB7TLH:5457:568^3^1^H99^		GB7DJK PC92^GB7TLH^82234^K^5GB7TLH:5457:568^3^1^H99^ *Note the build number attached to software version - 5GB7TLH:5457:568

	\|

	~~build~~ number -~~------------------'~~

	WR3D PC92^GB7TLH^82744^K^7GB7DJK-1:5453^1^1^H99^		WR3D PC92^GB7TLH^82744^K^7GB7DJK-1:5453^1^1^H99^

	The first for the main PC9X handling node and the second for an attached Legacy PC protocol node. The two fields at the end are <no of nodes> and <no of users> respectively. You should note the similarity of this and the traditional PC50.		The first for the main PC9X handling node and the second for an attached Legacy PC protocol node. The two fields at the end are <no of nodes> and <no of users> respectively. You should note the similarity of this and the traditional PC50.



	'''PC93 - Talk/Announce/WX'''		'''PC93 - Talk/Announce/WX'''

G0TRT: Added PC93 breakdown

2025-03-11T06:18:14Z

Added PC93 breakdown

← Older revision		Revision as of 06:18, 11 March 2025
Line 189:		Line 189:

	The first for the main PC9X handling node and the second for an attached Legacy PC protocol node. The two fields at the end are <no of nodes> and <no of users> respectively. You should note the similarity of this and the traditional PC50.		The first for the main PC9X handling node and the second for an attached Legacy PC protocol node. The two fields at the end are <no of nodes> and <no of users> respectively. You should note the similarity of this and the traditional PC50.


			'''PC93 - Talk/Announce/WX'''


			PC93^<node call>^<timestamp>^<to>^<from>^<via>^<text>[^<onode>][^<IPaddr>]^H99

			NOTES:

			* any ^ characters in <text> MUST be converted to %5E

			* <to> can be a callsign (a talk), if I can route to it, I treat it as a talk.

			WX (for weather).

			SYSOP (sysop announcements).

			<string> which is not recognised as a callsign by pattern recognition and is taken as a CHAT group (eg: LOGGER, #9000).

			* (announce/full).

			* <from> is the from users callsign

			* <via> constrains whether it goes via a particular node set to * for now.

			* <onode> is optional and is used when passing PC93s o.b.o non-PC9x handling nodes. Not currently used.

			This is an announce:

			PC93^IZ7AUH-6^79200^^IZ7AUH-6^^IZ7AUH-6 DX CLUSTER -> dx.iz7auh.net port 8000^^XX.XX.XX.XX^H97^

			This a talk:

			PC93^GB7TLH^81701^WR3D-2^G1TLH-2^*^wot?^H98^

			This is a Chat message:

			PC93^GB7TLH^81745^#9000^G1TLH-2^*^#48 anybody on?^H96^

			Note that for backwards compatibility all chat <text> sections have a serial number #1->#999 + a space added to it. The first chat message sent after restart should be a random no in that range. This is designed to defeat any de-duping on announces.

G0TRT at 06:13, 11 March 2025

2025-03-11T06:13:19Z

← Older revision		Revision as of 06:13, 11 March 2025
Line 1:		Line 1:
	{\| class="wikitable"		{\| class="wikitable"
	\|+ ~~Caption text~~		\|+ Legacy Protocols
	\|-		\|-
	! Topic !! Protocol		! Topic !! Protocol
Line 90:		Line 90:
	\|}		\|}

	~~New protocols~~

	{\| class="wikitable"		{\| class="wikitable"
	\|+ ~~Caption text~~		\|+ New protocols
	\|-		\|-
	! Topic !! Protocol !! Description		! Topic !! Protocol !! Description

G0TRT: Added some breakdowns - the format probably needs changing

2025-03-11T06:12:20Z

Added some breakdowns - the format probably needs changing

← Older revision		Revision as of 06:12, 11 March 2025
Line 107:		Line 107:
	\| Talk/Announce/WX \|\| PC93^<node call>^<timestamp>^<to>^<from>^<via>^<text>[^<onode>][^<IPaddr>]^H99 \|\| See breakdown below		\| Talk/Announce/WX \|\| PC93^<node call>^<timestamp>^<to>^<from>^<via>^<text>[^<onode>][^<IPaddr>]^H99 \|\| See breakdown below
	\|}		\|}
			'''PC92 - Routing'''

			The biggest change is that nodes only (ever) send their configuration (using a PC92) and the configuration of any directly connected "traditionally routing" nodes (TNODES) (ie still using PC16,17,19,21). The config stored of any TNODES is limited only to the local users on those nodes. Anything else is kept as hints, but is not transmitted onward, neither to other PC9x nodes nor other TNODES. The only configuration that other TNODES will see are the composite of all the PC92 nodes's configs + any other locally connected TNODES.

			PC92 Nodes periodically output their configuration. Failure to receive a config after 3 update periods will cause that node's config to be erased (and the changes to be propagated to any connected TNODEs). Think OSPF.

			All PC9x sentences contain a timestamp and the originating node call. This allows any of these sentences to be deduplicated and deliberate loops (for routing and new other functions) will allow things to continue to work as only "new" PC9x sentences will be processed.

			All PC9x sentences are passed onto neighbouring PC9x unaltered apart from a decremented hop count.

			Breakdown

			Ex. PC92^GB7TLH^78031^C^5GB7TLH:5457^1G1TLH-2:XX.XX.XX.XX^5GB7DJK^H99^

			GB7TLH - Originating Node

			78031 - Timestamp - seconds since midnight

			'C' current configuration record

			'A' records add nodes or users

			'D' records delete nodes or users.

			'K' keep alive records

			5GB7TLH:5457 ---.

			\|

			5 is a bit map which is made up like this:-

			Bit 1 - here/not here

			Bit 2 - external, traditional PC protocol node

			Bit 4 - Node

			1 - User/here

			4 - Node/not here - here flag is unset

			5 - Node/here

			7 - Traditional PC node/here

			GB7TLH is the callsign

			<nowiki>:</nowiki>5457 is the version number, other fields may be tacked on

			The first slot after the 'C', 'A' or 'D', is always reserved for the node call. This slot may be empty (as in ...^A^^1G1TLH^... as opposed to ..^A^5GB7TLH^1G1TLH^..) if the node is the same as the node call after PC92. Any software must be able to cope with this empty slot.

			The remaining payload...

			Bitmap/Call/:IPaddress

			Ex. 1G1TLH-2:XX.XX.XX.XX

			<nowiki>*</nowiki>Note: the IP address may not always be present at this time.

			H99 - hopcount


			Note that DXSpider converts PC16/17/19/21 from directly connected PC only nodes into PC92 that look like:-

			PC92^GB7TLH^78042^C^7GB7DJK-1:5453^1G1TLH-1^H99^

			This means that GB7TLH has PC node GB7DJK-1 with user G1TLH-1 attached to it.

			The principle being used here is similar to protocols like OSPF. A node only sends records that either come from it or PC nodes that it is "responsible" for. Nodes do not splurge out their local view of the network to cause even more confusion...

			'K' Record Examples - Keep Alive

			GB7DJK PC92^GB7TLH^82234^K^5GB7TLH:5457:568^3^1^H99^

			\|

			build number -------------------'

			WR3D PC92^GB7TLH^82744^K^7GB7DJK-1:5453^1^1^H99^

			The first for the main PC9X handling node and the second for an attached Legacy PC protocol node. The two fields at the end are <no of nodes> and <no of users> respectively. You should note the similarity of this and the traditional PC50.