Suggestion: Expose Native TCP/UDP Server & Client Components

[wuxi15]

Feature Suggestion
Hi Dext Author,
First of all, thank you for building such a clean, lightweight, and modern Delphi backend framework.
I would like to put forward a feature request: please expose native, standalone TCP / UDP server and client components in the Dext framework, including:

• TcpServer
• TcpClient
• UdpServer
• UdpClient
  Current Situation
  At present, Dext only exposes HTTP, REST and WebSocket services externally. The underlying TCP socket implementation is completely encapsulated and not open to developers. This makes Dext excellent for web API development, but unable to support custom private protocol communication, TCP long connection services, and UDP real-time data transmission.
  Why This Feature Is Needed
  Many Delphi backend scenarios require pure socket communication instead of HTTP-based services:
• Custom binary TCP private protocols (device communication, gateway service, industrial control)
• Long connection TCP server for message push and persistent connection
• High-speed, low-latency UDP data broadcasting and real-time transmission
• Custom socket client tools without HTTP protocol overhead
  Expected Design
  It would be perfect if Dext could provide independent, clean and high-performance socket interfaces, independent of HTTP/WebSocket modules:
• Expose standard TCP server/client for stream-based reliable communication
• Expose standard UDP server/client for connectionless datagram transmission
• Unified asynchronous callback design consistent with Dext’s modern coding style
• Keep the components lightweight, without redundant protocol encapsulation
  Benefits for Dext
  Opening native TCP/UDP socket components will greatly expand the application scope of Dext. The framework will no longer be limited to web API development, but can also cover network gateway, device service, real-time communication, and traditional socket server scenarios, making Dext a more comprehensive all-in-one Delphi backend framework.
  Thanks for your hard work and looking forward to this enhancement!

[cesarliws]

Hi @wuxi15,

First of all, thank you so much for the kind words! It is incredibly motivating to hear that you are enjoying Dext's clean and modern design. I've put a lot of heart into making it a high-performance framework.

Regarding your suggestion, you raised some very interesting points. However, I would like to share a bit about Dext's core philosophy and architecture to clarify why network communication is handled this way:

1. Dext's Philosophy: High-Performance Web & Enterprise Infrastructure

Dext was designed from day one to be a modern web/enterprise framework (similar to ASP.NET Core or Go Fiber) rather than a low-level network socket library. The main goal is to provide a fully integrated, high-performance stack for business systems.

2. Underlying Architecture (No Raw Sockets to Expose)

Under the hood, Dext doesn't implement or manage raw sockets directly at the application level. Instead, it leverages high-performance OS-native APIs (like HTTP.sys on Windows and epoll on Linux) to guarantee maximum throughput and stability. Because of this architecture, Dext doesn't actually have "native standalone socket components" built into the core framework that could be easily exposed to developers.

3. Roadmap & Enterprise Messaging Focus

Many of the use cases you mentioned (low latency, binary serialization, streaming, and persistent connections) are indeed on the radar, and we plan to address them using modern industry standards:

• gRPC & Protocol Buffers: We are currently developing and testing gRPC support, which offers high-performance binary communication and streaming, making it ideal for microservices and device communication.
• HTTP/3 & QUIC: We are also planning to work on HTTP/3 and QUIC (which runs over UDP), bringing the high-speed, low-latency benefits of UDP combined with modern security and flow control.
• Enterprise Messaging & Event-Streaming: For enterprise integration, we are keeping a close eye on protocols like MQTT (for IoT/devices), AMQP, STOMP, and integrations with stream engines like Apache Kafka or RabbitMQ Stream. If the community demand takes us there, we will focus on providing high-level, production-ready adapters for these systems.

Ultimately, the goal is to follow where enterprise demand takes the project, focusing on delivering high-value, robust abstractions for modern business architectures rather than raw network plumbing.

I’d Love to Understand Your Use Case!

Could you share a bit more about the specific scenario you are facing? For example, are you building integration with specific industrial IoT devices, or implementing a custom legacy protocol?

Understanding your concrete needs will help us think about how Dext can support you—whether through the upcoming gRPC engine, WebSockets, or potentially by designing a plugin/provider extension model in the future.

Thank you again for helping me shape the future of Dext!

Cesar Romero

[cesarliws]

Hi @wuxi15,

I'm happy to share that we have just finalized the implementation of Spec S47 (Expose TCP/UDP & MQTT Server/Client) natively on top of Dext's core I/O engines!

What's New

1. Engine Decoupling (IConnectionHandler): We decoupled the core Winsock IOCP (Windows) and Epoll (Linux) engines from standard HTTP parsing. You can now supply custom protocol handlers directly to bind raw socket payloads.
2. TCP & UDP Components: Standalone TDextTcpServer, TDextTcpClient, TDextUdpServer, and TDextUdpClient are now available in the Dext.Net namespace, utilizing high-performance non-blocking I/O.
3. Native MQTT v3.1.1: We implemented a lightweight, zero-allocation binary encoder/decoder, a wildcard topic-matching Trie tree router (+ and #), a non-blocking TDextMqttClient, and a concurrent broker server TDextMqttServer.

Documentation

We have added comprehensive chapters to the Dext Book detailing how to set up both raw sockets and MQTT services:

• Low-Level Sockets Guide: Docs/Book/12-networking/low-level-sockets.md
• MQTT Protocol Guide: Docs/Book/12-networking/mqtt.md

Test Suite

We also added a new automated integration test suite confirming connection loops and pub/sub routing:

• Test File: Tests/Net/Dext.Net.Mqtt.Tests.pas

---

We would love to count on your help to pull the latest updates, integrate these components into your IoT/industrial gateway projects, and report back on how they perform under your target load. If you encounter any unexpected behavior, please let us know by opening an issue!

Thanks again for your support and feedback!