tanvir-ahmed-m4/hub4com

Purpose and runtime

hub4com is a native Windows communications hub in the com0com ecosystem. It opens serial or TCP endpoints, routes data/control signals among them, and can transform streams through dynamically loaded filter plugins. The main executable is built from hub4com.cpp, with Visual C++ project metadata in hub4com.vcproj and solution hub4com.sln.

Process startup and configuration

hub4com.cpp is the command-line entry point. It parses ordered options and endpoint declarations, including inline/load-file configurations, then builds the hub topology. Configuration is operationally significant: route declarations, selected port driver, queue/reconnect behavior, and filter attachment determine runtime behavior. Core command/status messaging is centralized in hubmsg.cpp and hubmsg.h.

Hub orchestration

comhub.cpp / comhub.h implement the central coordinator over all opened ports. It owns lifecycle sequencing and distributes port events into routing/filter processing. timer.cpp / timer.h support timed behavior such as reconnect intervals, making connection management part of the hub control plane rather than a transport-specific concern.

Ports and endpoint-driver boundary

The abstract port contract is defined by port.cpp / port.h. Concrete endpoint implementations are supplied as plugins, separating the core hub from Windows serial and socket transport details:

• Serial transport: plugins/serial/port.cpp, plugins/serial/comport.cpp, plugins/serial/comio.cpp

• TCP transport: plugins/tcp/port.cpp, plugins/tcp/comport.cpp, plugins/tcp/comio.cpp

• Connector transport: plugins/connector/port.cpp, plugins/connector/comport.cpp

TCP endpoints support client/server-style address forms; serial endpoints integrate physical and com0com virtual COM ports. External infrastructure is Windows serial I/O, TCP/IP networking, and optionally the com0com virtual-null-modem driver.

Routing and backpressure

route.cpp / route.h define directed relationships between port indices. The hub can fan input out to multiple destinations, implement bidirectional routes, and propagate relevant control/flow signals. Per-port write queues and connection state form the key boundary between routing intent and endpoint availability; reconnect and queue-limit settings prevent a failed TCP peer from necessarily blocking unrelated routes.

Filter pipeline and plugin ABI

filter.h, filters.cpp, and filters.h provide the core filter-chain mechanism. Plugins are discovered/loaded through plugins.cpp / plugins.h, against the shared interface in plugins/plugins_api.h and export definitions in plugins/plugins.def. Filters can be attached by port/route configuration and transform bytes or communications signals before forwarding.

Architecturally important supplied filters include Telnet/RFC 2217 handling (plugins/telnet/telnet.cpp, plugins/telnet/opt_comport.cpp), encryption-oriented transformation (plugins/crypt/filter.cpp), multiplexing/tagging (plugins/tag/filter.cpp), tracing (plugins/trace/filter.cpp), and pin/control-line mapping (plugins/pinmap/filter.cpp, plugins/pin2con/filter.cpp).

Deployment compositions

The executable is intentionally topology-driven rather than application-server-driven. Batch wrappers compose reusable configurations for common deployments: COM-to-TCP/Telnet in examples/com2tcp.bat, RFC 2217 in examples/com2tcp-rfc2217.bat, and encrypted or serial-link multiplexing in examples/multiplexer.bat. A static-build variant exists in static/hub4com-static.vcproj.