P2Pmsgcore — the routing kernel

One address.
Any transport.
Every message routed.

A hub owns an address on a virtual network, keeps a priority queue, and runs pump threads that hand each message to a handler. Where the peer actually lives — same process, next machine, other side of a serial cable — is a choice of connection class, not a rewrite. P2Pmsgcore has been doing this in production since 2002.

See the walkthrough → Libraries & downloads

Connection classes converge · one queue · shared pumps · mapped handlers

2002Kernel in service since

1Pump per thread, none per peer

4Transports in the box

1Address space, wire to wire

Two products

One kernel underneath

Flagship — developer library

P2Pmsgcore

C++ · Java · Windows & Linux

The message routing kernel. Hubs take hierarchical addresses, messages carry a priority and a code, and handlers are bound by map macros. Connection state and message dispatch are pumped through shared threads, so a connection costs an object — not a thread.

Hierarchical virtual addressing, independent of IP
Priority message queue with pooled pump threads
Self-describing hierarchical message payloads
Diffie–Hellman key exchange and AES payload encryption
Overlapped, non-blocking I/O with no thread per peer

Walkthrough → Architecture

Application — built on P2Pmsgcore

Chartboard

Technical analysis workspace · Windows

A workspace-centred charting, portfolio, modelling and scanning application. Every internal component talks over the same message kernel, which is how the embedded Python interpreter, the paged datastore and the chart engine stay decoupled.

OHLC and Point & Figure charts, fully serialised
Thirty-odd oscillators, twenty-odd overlays, harmonics and regressions
Paged in-memory datastore — no SQL server to deploy
Python 3.11 advisor, modelling and scanner scripts
Portfolio positions, trade modelling and market replay

Explore Chartboard → Free download

Same hub, different wire

Transports

A connection is a typed transport bolted to a hub. Swap the class and the routing is unchanged — the address, the queue and the map stay exactly as they are.

P2PeerConWsaTCP sockets over the network

P2PeerConPipeNamed pipes between local processes

P2PeerCon232RS-232 serial to attached hardware

P2PeerConDmxDirect memory exchange inside one process

Bridges to the rest of the estate

Integrations

Each of these is a hub with a second, dedicated pump: the primary context keeps pre-empting and routing messages while the specialist pump serialises whatever the foreign API insists on serialising.

P2PmsgODBC

SQL Server

Accepts SQL statements as messages and streams the result set back to the requesting address, one message at a time.

P2PmsgMFC

MFC user interfaces

Patterns and controls that let CTreeCtrl, CListCtrl, CComboBox and CDialog participate asynchronously in the message flow.

P2PmsgMAPI

Outlook & MAPI

Wrappers for IMAPISession, IMsgStore, IMAPIFolder and IMessage, with a MAPI pump dedicated to the serial mail stream.

AKAserva

HTTP & WebSocket

A web server built entirely from the kernel. Requests parse into messages, get decorated by handlers, and translate back into responses.

P2PmsgVoIP

Audio & VoIP

WAVEHDR and WAVEFORMATEX wrapped into a hub, so audio frames move through the same queue as everything else.

AKAssms · SQLmapi

Reference applications

Full Visual Studio solutions built on the libraries — a SQL object explorer and a mail dispatcher — usable as test benches.

Watch a message get routed

Eight calls, start to finish

Name the hub, allocate it, map a code, start the pumps, listen, accept a peer, exchange keys, and post a message. The walkthrough steps through all eight with the caller code and the event log beside it.

Open the walkthrough →

One address.Any transport.Every message routed.