PC Packet Cluster Protocol - Revision history

Dxcadmin at 21:32, 22 November 2025

2025-11-22T21:32:04Z

← Older revision		Revision as of 21:32, 22 November 2025
Line 13:		Line 13:
	I have tried to show what is actually being used, as opposed to what is documented. What is shown here is therefore my impression of how it looks and what the fields do - YMMV.		I have tried to show what is actually being used, as opposed to what is documented. What is shown here is therefore my impression of how it looks and what the fields do - YMMV.

	{\|		{\| class="wikitable" style="margin:auto"
	\|-		\|-
	\|Talk mode\|\|PC10^from-user^to-user^msg^bell-flag^ ^from-node^~		\|Talk mode\|\|PC10^from-user^to-user^msg^bell-flag^ ^from-node^~

Dxcadmin at 21:30, 22 November 2025

2025-11-22T21:30:13Z

← Older revision		Revision as of 21:30, 22 November 2025
Line 1:		Line 1:
	The PC Packet Cluster Protocol		== The PC Packet Cluster Protocol ==

	Introduction		=== Introduction ===

	The PC Packet Cluster protocol is used to communicate between two DX Cluster nodes. It is an ASCII protocol that is designed to work in a directed graph with no loops or duplicate routes. Unfortunately, in this modern world, that is exactly what we want to do! If you would like to participate in the discussion for a replacement protocol please join the Cluster-tech mailing list.		The PC Packet Cluster protocol is used to communicate between two DX Cluster nodes. It is an ASCII protocol that is designed to work in a directed graph with no loops or duplicate routes. Unfortunately, in this modern world, that is exactly what we want to do! If you would like to participate in the discussion for a replacement protocol please join the Cluster-tech mailing list.

	Basic Format		=== Basic Format ===

	Each protocol message started with the letters PC, each protocol message is sent in packet by itself and is terminated with a carriage return character. The letters PC are followed by two digits starting at 10. All the fields in the message are separated with the ^ character. The last field may be terminated by a ^ or a ^~ sequence. I don't know why. All fields are in ASCII.		Each protocol message started with the letters PC, each protocol message is sent in packet by itself and is terminated with a carriage return character. The letters PC are followed by two digits starting at 10. All the fields in the message are separated with the ^ character. The last field may be terminated by a ^ or a ^~ sequence. I don't know why. All fields are in ASCII.

	The Message Formats		=== The Message Formats ===

	I have tried to show what is actually being used, as opposed to what is documented. What is shown here is therefore my impression of how it looks and what the fields do - YMMV.		I have tried to show what is actually being used, as opposed to what is documented. What is shown here is therefore my impression of how it looks and what the fields do - YMMV.
Line 99:		Line 99:
	\|}		\|}

	Glossary		=== Glossary ===

	Some of the terms used above are explained		Some of the terms used above are explained

	node		==== node ====
	The Callsign of a node		The Callsign of a node

	user		==== user ====
	The Callsign of a user on a node		The Callsign of a user on a node

	Route-to\|from\|via-node		==== Route-to\|from\|via-node ====
	Route this message via the nodes specified. Usually the 'route-to-node' callsign is pointed to the node receiving this sentence (ie the directly connected neighbour), but this is not a requirement. Nodes should obey the routing even if the callsign isn't the local one. This is the method used to (for instance) pass messages direct from one node to another via one or more intervening nodes without the usual store and forward. It also allows nodes request files from nodes more than one hop away.		Route this message via the nodes specified. Usually the 'route-to-node' callsign is pointed to the node receiving this sentence (ie the directly connected neighbour), but this is not a requirement. Nodes should obey the routing even if the callsign isn't the local one. This is the method used to (for instance) pass messages direct from one node to another via one or more intervening nodes without the usual store and forward. It also allows nodes request files from nodes more than one hop away.

	origin-node		==== origin-node ====
	This is node upon which this sentence originated. This field should never be changed by any intervening node.		This is node upon which this sentence originated. This field should never be changed by any intervening node.

	stream-no		==== stream-no ====
	This is a number issued by the receiving node in (for instance) message handling and is used as a key for both ends to distinguish one stream of similar sentences from another. In theory, it is possible for node to send more than one message to the same other node at a time. Each message is distinguished from the other by the stream no.		This is a number issued by the receiving node in (for instance) message handling and is used as a key for both ends to distinguish one stream of similar sentences from another. In theory, it is possible for node to send more than one message to the same other node at a time. Each message is distinguished from the other by the stream no.

Dxcadmin at 21:21, 22 November 2025

2025-11-22T21:21:29Z

Show changes

Dxcadmin at 21:14, 22 November 2025

2025-11-22T21:14:01Z

← Older revision		Revision as of 21:14, 22 November 2025
Line 12:		Line 12:

	I have tried to show what is actually being used, as opposed to what is documented. What is shown here is therefore my impression of how it looks and what the fields do - YMMV.		I have tried to show what is actually being used, as opposed to what is documented. What is shown here is therefore my impression of how it looks and what the fields do - YMMV.

			{\| class="wikitable" style="margin:auto"
			\|+ Caption text
			\|-
			! Header text !! Header text !! Header text
			\|-
			\| Example \|\| Example \|\| Example
			\|-
			\| Example \|\| Example \|\| Example
			\|-
			\| Example \|\| Example \|\| Example
			\|}

	Talk mode PC10^from-user^to-user^msg^bell-flag^ ^from-node^~		Talk mode PC10^from-user^to-user^msg^bell-flag^ ^from-node^~

Dxcadmin: Created page with "The PC Packet Cluster Protocol Introduction The PC Packet Cluster protocol is used to communicate between two DX Cluster nodes. It is an ASCII protocol that is designed to work in a directed graph with no loops or duplicate routes. Unfortunately, in this modern world, that is exactly what we want to do! If you would like to participate in the discussion for a replacement protocol please join the Cluster-tech mailing list. Basic Format Each protocol message started wi..."

2025-11-22T21:13:41Z

Created page with "The PC Packet Cluster Protocol Introduction The PC Packet Cluster protocol is used to communicate between two DX Cluster nodes. It is an ASCII protocol that is designed to work in a directed graph with no loops or duplicate routes. Unfortunately, in this modern world, that is exactly what we want to do! If you would like to participate in the discussion for a replacement protocol please join the Cluster-tech mailing list. Basic Format Each protocol message started wi..."

New page

The PC Packet Cluster Protocol

Introduction

The PC Packet Cluster protocol is used to communicate between two DX Cluster nodes. It is an ASCII protocol that is designed to work in a directed graph with no loops or duplicate routes. Unfortunately, in this modern world, that is exactly what we want to do! If you would like to participate in the discussion for a replacement protocol please join the Cluster-tech mailing list.

Basic Format

Each protocol message started with the letters PC, each protocol message is sent in packet by itself and is terminated with a carriage return character. The letters PC are followed by two digits starting at 10. All the fields in the message are separated with the ^ character. The last field may be terminated by a ^ or a ^~ sequence. I don't know why. All fields are in ASCII.

The Message Formats

I have tried to show what is actually being used, as opposed to what is documented. What is shown here is therefore my impression of how it looks and what the fields do - YMMV.

Talk mode PC10^from-user^to-user^msg^bell-flag^ ^from-node^~
PC10^from-user^route-via-node^msg^bell-flag^to-user^origin-node^~
DX info PC11^DXfreq^DXcall^date^time^comment-txt^user-rprt^origin-node^hops^~
Announcement PC12^from-user^route-to-node^msg^sysop-flg^origin-node^wx-flg^hops^~
Stn into CONF PC13^user^hops^
Stn out of CONF PC14^user^hops^
Conference Mode PC15^from-user^msg^hops^~
PC user add PC16^node^user talk-mode here^user talk-mode here^...^hops^
PC user delete PC17^user^node^hops^
PC initialization: RequestInit PC18^cluster info^ver^
PC initialization: NodeAdd PC19^here^node^talk^ver^...^hops^
PC initialization: InitDone PC20^
PC initialization: NodeDelete PC21^node^reason^hops^
PC initialization: PCDone PC22^
WWV info PC23^date^hour^SFI^A^K^forecast^logger^origin-node^hops^~
Here status info PC24^user^here^hops^
DX/WWV merge req PC25^route-to-node^route-from-node^DX-cnt^WWV-cnt^
Merge DX info PC26^DXfreq^DXcall^date^time^comment-txt^spotter^origin-node^ ^~
Merge WWV info PC27^date^hour^SFI^A^K^forecast^logger^origin-node^ ^~
PC Mail: SendSubject PC28^route-to-node^route-from-node^to-user^from-user^date^time^private-flg^subject^bbs^no-lines^rr-flg^via-node^origin-node^~
PC Mail: SendText PC29^route-to-node^route-from-node^stream-no^text^~
PC Mail: AckSubject PC30^route-to-node^route-from-node^stream-no^
PC Mail: AckText PC31^route-to-node^route-from-node^stream-no^
PC Mail: CompleteText PC32^route-to-node^route-from-node^stream-no^
PC Mail: AckCompleteText PC33^route-to-node^route-from-node^stream-no^
Remote commands: Command PC34^route-to-node^route-from-node^cmd^~
Remote commands: Response PC35^route-to-node^route-from-node^cmd-resp^~
Remote commands: Show Command PC36^route-to-node^route-from-node^cmd^~
Remote commands: Needs db update PC37^route-to-node^route-from-node^user^stream-no^cmd^~
PC initialization: Connected nodes PC38^node,node,...^~
NodeDelete w/Discon PC39^node^reason^
PC file forward PC40^route-to-node^route-from-node^filename^bulletin^linecnt^
User info PC41^user^type^info^hops^~
Forwarding abort PC42^route-to-node^route-from-node^stream-no^
Remote DB request PC44^route-to-node^route-from-node^stream-no^qualifier^key^user^
Remote DB response PC45^route-to-node^route-from-node^stream-no^info^~
Remote DB complete PC46^route-to-node^route-from-node^stream-no^
Remote DB update PC47^route-to-node^route-from-node^user^qualifier^key^stream-no^
Remote userDB req PC48^route-to-node^route-from-node^stream-no^qualifier^key^user^
Bulletin delete PC49^from-user^subject^hops^
Local User count PC50^node^user-count^hops^
Ping PC51^route-to-node^route-from-node^ping-flag^

Glossary

Some of the terms used above are explained

node
The Callsign of a node

user
The Callsign of a user on a node

Route-to|from|via-node
Route this message via the nodes specified. Usually the 'route-to-node' callsign is pointed to the node receiving this sentence (ie the directly connected neighbour), but this is not a requirement. Nodes should obey the routing even if the callsign isn't the local one. This is the method used to (for instance) pass messages direct from one node to another via one or more intervening nodes without the usual store and forward. It also allows nodes request files from nodes more than one hop away.

origin-node
This is node upon which this sentence originated. This field should never be changed by any intervening node.

stream-no
This is a number issued by the receiving node in (for instance) message handling and is used as a key for both ends to distinguish one stream of similar sentences from another. In theory, it is possible for node to send more than one message to the same other node at a time. Each message is distinguished from the other by the stream no.