# Sgcwebsockets Dotnet Mq

> sgcWebSockets .NET Message Brokers

- Skill: `esegece-com/sgcwebsockets-dotnet-mq` (Agent Skill, multi-file: 169 files)
- Install (CLI): `npx skillmds@latest add esegece-com/sgcwebsockets-dotnet-mq`
- Raw SKILL.md: https://api.skillmd.com/api/skills/esegece-com/sgcwebsockets-dotnet-mq/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: esegece-com (https://skillmd.com/u/esegece-com)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/esegece-com/sgcwebsockets-dotnet-mq

---


# sgcWebSockets .NET Message Brokers

Eight components that speak the wire protocols of the common message brokers.
None of them owns a socket. Each attaches to a transport client through its
`Client` property, and the transport is what connects, reconnects and does TLS.
Get that relationship right and the rest follows.

Read `sgcwebsockets-dotnet` first for the transport client and the threading
rule, both of which apply here unchanged.

## When to use this skill

- Publish to or subscribe from an MQTT broker (Mosquitto, HiveMQ, EMQX)
- Talk STOMP to RabbitMQ or ActiveMQ
- Talk AMQP 0.9.1 to RabbitMQ, or AMQP 1.0 to a broker that speaks it
- Produce to or consume from Kafka
- Call and subscribe over WAMP2

## Components in this skill

| Protocol | Component |
| --- | --- |
| MQTT 3.1.1 and 5 | `TsgcWSPClient_MQTT` |
| STOMP | `TsgcWSPClient_STOMP` |
| STOMP, RabbitMQ dialect | `TsgcWSPClient_STOMP_RabbitMQ` |
| STOMP, ActiveMQ dialect | `TsgcWSPClient_STOMP_ActiveMQ` |
| AMQP 0.9.1 | `TsgcWSPClient_AMQP` |
| AMQP 1.0 | `TsgcWSPClient_AMQP1` |
| Kafka | `TsgcWSPClient_Kafka` |
| WAMP2 | `TsgcWSPClient_WAMP2` |

## Before you start, ask the developer

Use a structured question tool if your host has one, for example Claude Code's
`AskUserQuestion`. Otherwise ask in chat:

1. **Which broker, and which port?** A broker on 1883 or 5672 is plain TCP, not
   WebSocket, and that changes one setting on the transport. See below.
2. **MQTT 3.1.1 or 5?** `MQTTVersion` picks it. Version 5 adds the properties
   and reason codes; a version 5 feature against a 3.1.1 broker is refused.
3. **What QoS?** 0, 1 and 2 are three different delivery contracts and three
   different amounts of work. Ask rather than defaulting.
4. **Does the application need to know it lost messages?** That decides whether
   you need a last will, a clean session, or both.

## Quickstart, MQTT

```csharp
using esegece.sgcWebSockets;

var client = new TsgcWebSocketClient();
client.Host = "test.mosquitto.org";
client.Port = 8080;

var mqtt = new TsgcWSPClient_MQTT();
mqtt.Client = client;                       // the socket lives on the client
mqtt.MQTTVersion = TwsMQTTVersion.mqtt311;

mqtt.OnMQTTConnect += (TsgcWSConnection connection, bool session,
    int reasonCode, string reasonName,
    TsgcWSMQTTCONNACKProperties properties) =>
        mqtt.Subscribe("sgcWebSockets/test");

mqtt.OnMQTTPublish += (TsgcWSConnection connection, string topic, string text,
    TsgcWSMQTTPublishProperties properties) =>
        Console.WriteLine(topic + ": " + text);

client.Active = true;                        // connects the socket
```

`Subscribe`, `UnSubscribe` and `Publish(topic, text)` are the everyday methods.
`PublishAndWait(topic, text, qos, timeout)` returns a bool and is the one to
reach for when the application has to know the broker took it.

Check the delegate signatures on the type pages before writing a handler. The
MQTT events carry several parameters and the order is not guessable.

## Plain TCP brokers, the setting people miss

A broker on port 1883, 5672 or 61613 speaks its protocol over raw TCP, not over
WebSocket. On the transport client set:

```csharp
client.Specifications.RFC6455 = false;
```

Without it the client sends a WebSocket handshake, the broker does not answer
one, and the connection dies with something that reads like a network fault. A
broker reached on 8080 or 443 usually is over WebSocket and wants the default.

## Things that catch people out

- Setting `Active = true` on the protocol component does nothing useful. The
  transport client owns the connection; start that.
- One transport carries one protocol. Two protocol components pointed at the
  same client is the usual cause of a broker rejecting the handshake.
- `Client` is typed `TsgcTCPComponent_Client`, so a plain `TsgcTCPClient` works
  as the transport for a TCP broker. That is a feature, not an accident.
- MQTT has two heartbeats: `HeartBeat` on the MQTT component is the protocol
  keepalive, and `HeartBeat` on the transport client is the WebSocket ping.
  They are different mechanisms with the same name.
- Reconnect belongs to the transport. Set `client.WatchDog`, not anything on
  the protocol component.
- QoS 2 is a four-message exchange. Tracking delivery yourself means handling
  `OnMQTTPubRec`, `OnMQTTPubRel` and `OnMQTTPubComp`, not just `OnMQTTPubAck`.
- `Disconnect` on the MQTT component takes a reason code, an int. It is the
  MQTT 5 disconnect reason, and it is not a timeout.

## Routing

- **API detail**: `reference/api/<Component>.md` has the properties, events and methods, each with its C# signature.
- **Option / enum / delegate types**: property and event types link to `reference/types/<TypeName>.md`.
- **Examples**: `examples/<Component>.md` is a trimmed snippet from the shipped demo; `examples/index.md` maps every component to its demo.
- **Getting started**: `concepts/overview.md` covers the single `using`, the target frameworks and the naming.

## What is documented

Public instance properties, events and methods declared anywhere in the
library's own class chain. Members inherited from the .NET base classes are
left out, as are internals, so a page shows the surface a caller writes
against and nothing else.

If a component you need is not here, read `concepts/coverage.md` in the
`sgcwebsockets-dotnet` skill before assuming a different name for it.
This assembly carries fewer components than the Delphi library, and saying
so is more useful than guessing an API that does not exist.