> For the complete documentation index, see [llms.txt](https://dnotifier.gitbook.io/product-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dnotifier.gitbook.io/product-docs/realtime-communication/chunking.md).

# Large messages & chunking

DNotifier SDKs **automatically split** payloads larger than your plan's per-chunk limit and **reassemble** them on the receiver before `onMessage` fires. You send one logical message; recipients always see the complete payload.

***

## How chunking works

```
  send(large payload)
         │
         ▼
  SDK compares size to messageSizeLimit
         │
         ├── fits in one chunk → single frame
         │
         └── too large → split into N chunks
                    │
                    ▼
              each chunk framed with metadata
              (packet index, total count, message id)
                    │
                    ▼
              receiver SDK buffers chunks
                    │
                    ▼
              all N received → merge → onMessage(complete payload)
```

You do **not** implement chunking logic unless you are building a custom transport client.

***

## `messageSizeLimit`

After `connect()`, read the limit from the client:

```js
await notifier.connect();
console.log(notifier.messageSizeLimit); // bytes, from your plan
```

```dart
await notifier.connect();
print(notifier.messageSizeLimit);
```

This value is also available via `getPlanLimits()`. It defines the **maximum size of each chunk**, not necessarily the total message size — multi-chunk messages can exceed this limit in total.

{% hint style="info" %}
Default chunk size is plan-dependent (commonly 32 KB per chunk). Upgrade your plan or contact support if you need higher per-chunk limits.
{% endhint %}

***

## What gets chunked

| API                                               | Chunked automatically       |
| ------------------------------------------------- | --------------------------- |
| `send()` with large `data.content` (images, docs) | Yes                         |
| `sendBinary()` with large `buffer`                | Yes                         |
| Small text messages                               | No — sent in a single frame |

***

## Receiver behavior

Your `onMessage` handler always receives a **complete** reassembled message:

```js
onMessage: (msg) => {
  // This fires only after all chunks arrive
  const body = msg.payload.toJSON();
  // body.content is the full image bytes, not a partial chunk
},
```

If the connection drops mid-chunk, the partial buffer is discarded. The sender may retry after reconnect.

***

## Best practices

1. **Check limits at connect** — gate file uploads in UI when files exceed reasonable bounds
2. **Show upload progress locally** — DNotifier does not expose per-chunk send progress; track read/upload in your app
3. **Prefer structured `send()`** for media — chunking, history, and typed handlers work together
4. **Compress before send** — reduce chunk count for very large payloads when your format allows

***

## Plan relationship

Message volume and size limits count toward your plan quotas. See [Plan limits & quotas](/product-docs/realtime-communication/plan-limits.md) and [Pricing & plans](/product-docs/platform-overview/pricing.md).

***

## Related topics

* [Structured payloads](/product-docs/realtime-communication/structured-payloads.md)
* [Binary messaging](/product-docs/realtime-communication/binary-messaging.md)
* [Error handling & reconnection](/product-docs/realtime-communication/error-handling.md)