Skip to content

qkc/slave 04: implement RpcConn and XshardConn compatibility layer#32

Open
iteyelmp wants to merge 5 commits into
slave-03from
slave-04
Open

qkc/slave 04: implement RpcConn and XshardConn compatibility layer#32
iteyelmp wants to merge 5 commits into
slave-03from
slave-04

Conversation

@iteyelmp

@iteyelmp iteyelmp commented Jul 10, 2026

Copy link
Copy Markdown

This PR introduces the foundational connection layer used by future cluster communication components:

  • RpcConn
  • XshardConn
  • XshardPool

The focus of this PR is protocol compatibility and connection behavior rather than business logic migration.

Implemented

Connection framework

  • RpcConn request/response framework
  • RPC ID tracking and validation
  • pending RPC lifecycle management
  • connection close propagation
  • handler dispatch and error handling

Xshard communication layer

  • XshardConn
  • XshardPool
  • peer identity verification
  • reconnect handling

Protocol support

  • slave-slave PING/PONG
  • RPC request/response matching
  • connection lifecycle handling

Compatibility Validation

Verified against the Python implementation:

  • opcode mappings
  • field ordering
  • Optional/nil serialization semantics
  • frame format compatibility
  • PING/PONG interoperability
  • RPC request/response interoperability
  • connection close behavior
  • pool reconnect behavior

The compatibility tests use a real Python peer process and validate Go↔Python communication over TCP.

Testing

Two categories of tests are included:

Unit tests

Validate Go-side connection behavior:

  • RPC ID validation
  • pending RPC lifecycle
  • connection close semantics
  • panic/error handling

Python compatibility tests

Validate interoperability with the Python implementation:

  • Python → Go PING/PONG
  • Go → Python PING/PONG
  • RPC request/response matching
  • connection close propagation
  • pool reconnect behavior

These compatibility tests establish the reusable test infrastructure that future cluster communication components (e.g. MasterConn and other cluster connection types) can build upon.

Out of Scope

This PR does not migrate cluster business logic.

The following are intentionally deferred to later PRs:

  • MasterConn
  • higher-level cluster message handling
  • cluster business workflows
  • full cluster integration
  • message-specific compatibility coverage for all protocol message types

@iteyelmp
iteyelmp changed the base branch from goshard/base to slave-03 July 10, 2026 03:30
@iteyelmp
iteyelmp changed the base branch from slave-03 to goshard/base July 13, 2026 02:24
@iteyelmp
iteyelmp changed the base branch from goshard/base to slave-03 July 16, 2026 09:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant