@apocaliss92/nodelink-js 0.6.1 → 0.6.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.d.cts CHANGED
@@ -291,9 +291,44 @@ declare function decodeHeader(buf: AnyBuffer): {
291
291
  * - expects each message to start with the magic header
292
292
  * - supports multiple messages per TCP chunk
293
293
  * - waits for full body before emitting
294
+ *
295
+ * Accumulation strategy: incoming chunks are appended to a pending list
296
+ * (O(1) per chunk) and only concatenated into a contiguous `this.buffer`
297
+ * when a parse is actually attempted. This avoids the previous O(n²)
298
+ * behavior where every TCP chunk re-copied the whole retained buffer —
299
+ * costly for large video frames fragmented across many small chunks.
300
+ *
301
+ * The observable behavior (the exact sequence of frames emitted, magic
302
+ * realignment, multi-message chunks, waiting for a complete body) is
303
+ * identical to the prior `Buffer.concat`-per-chunk implementation.
294
304
  */
295
305
  declare class BaichuanFrameParser {
306
+ /** Retained-but-unconsumed contiguous bytes from previous push() calls. */
296
307
  private buffer;
308
+ /** Chunks received since the last materialization, not yet concatenated. */
309
+ private pending;
310
+ /** Total bytes held in `pending` (kept in sync to avoid re-summing). */
311
+ private pendingLen;
312
+ /**
313
+ * Total contiguous bytes (`buffer` + `pending`) required before the next
314
+ * parse attempt can make progress. While buffered bytes stay below this,
315
+ * incoming chunks are merely stashed in `pending` with no copy. This is
316
+ * the mechanism that turns the worst case (a large frame fragmented over
317
+ * many small TCP chunks) from O(n²) into O(n): we concatenate once, when
318
+ * enough bytes have arrived, instead of on every chunk.
319
+ *
320
+ * Starts at 4 — the minimum needed to inspect the magic header.
321
+ */
322
+ private needed;
323
+ /**
324
+ * Collapse `this.buffer` + all `pending` chunks into a single contiguous
325
+ * buffer. The retained leftover is copied at most once per materialize(),
326
+ * and materialize() only runs when `needed` bytes are available — so a
327
+ * fragmented frame is assembled with a single concat, not one per chunk.
328
+ */
329
+ private materialize;
330
+ /** Total buffered bytes, whether materialized or still pending. */
331
+ private get available();
297
332
  push(chunk: Buffer): BaichuanFrame[];
298
333
  }
299
334
 
package/dist/index.d.ts CHANGED
@@ -1166,9 +1166,44 @@ export declare type BaichuanFrame = {
1166
1166
  * - expects each message to start with the magic header
1167
1167
  * - supports multiple messages per TCP chunk
1168
1168
  * - waits for full body before emitting
1169
+ *
1170
+ * Accumulation strategy: incoming chunks are appended to a pending list
1171
+ * (O(1) per chunk) and only concatenated into a contiguous `this.buffer`
1172
+ * when a parse is actually attempted. This avoids the previous O(n²)
1173
+ * behavior where every TCP chunk re-copied the whole retained buffer —
1174
+ * costly for large video frames fragmented across many small chunks.
1175
+ *
1176
+ * The observable behavior (the exact sequence of frames emitted, magic
1177
+ * realignment, multi-message chunks, waiting for a complete body) is
1178
+ * identical to the prior `Buffer.concat`-per-chunk implementation.
1169
1179
  */
1170
1180
  export declare class BaichuanFrameParser {
1181
+ /** Retained-but-unconsumed contiguous bytes from previous push() calls. */
1171
1182
  private buffer;
1183
+ /** Chunks received since the last materialization, not yet concatenated. */
1184
+ private pending;
1185
+ /** Total bytes held in `pending` (kept in sync to avoid re-summing). */
1186
+ private pendingLen;
1187
+ /**
1188
+ * Total contiguous bytes (`buffer` + `pending`) required before the next
1189
+ * parse attempt can make progress. While buffered bytes stay below this,
1190
+ * incoming chunks are merely stashed in `pending` with no copy. This is
1191
+ * the mechanism that turns the worst case (a large frame fragmented over
1192
+ * many small TCP chunks) from O(n²) into O(n): we concatenate once, when
1193
+ * enough bytes have arrived, instead of on every chunk.
1194
+ *
1195
+ * Starts at 4 — the minimum needed to inspect the magic header.
1196
+ */
1197
+ private needed;
1198
+ /**
1199
+ * Collapse `this.buffer` + all `pending` chunks into a single contiguous
1200
+ * buffer. The retained leftover is copied at most once per materialize(),
1201
+ * and materialize() only runs when `needed` bytes are available — so a
1202
+ * fragmented frame is assembled with a single concat, not one per chunk.
1203
+ */
1204
+ private materialize;
1205
+ /** Total buffered bytes, whether materialized or still pending. */
1206
+ private get available();
1172
1207
  push(chunk: Buffer): BaichuanFrame[];
1173
1208
  }
1174
1209
 
package/dist/index.js CHANGED
@@ -69,7 +69,7 @@ import {
69
69
  setGlobalLogger,
70
70
  tcpReachabilityProbe,
71
71
  xmlIndicatesFloodlight
72
- } from "./chunk-EAHRVNEX.js";
72
+ } from "./chunk-D4TKRGUP.js";
73
73
  import {
74
74
  ReolinkCgiApi,
75
75
  ReolinkHttpClient,
@@ -116,7 +116,7 @@ import {
116
116
  upsertXmlTag,
117
117
  xmlEscape,
118
118
  zipDirectory
119
- } from "./chunk-XDVBNZGR.js";
119
+ } from "./chunk-IQVVVSXO.js";
120
120
  import {
121
121
  AesStreamDecryptor,
122
122
  BC_AES_IV,
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@apocaliss92/nodelink-js",
3
- "version": "0.6.1",
3
+ "version": "0.6.2",
4
4
  "description": "TypeScript library implementing Reolink Baichuan protocol (control + streaming) with CGI and RTSP helpers. Full TypeScript support with comprehensive type definitions.",
5
5
  "license": "MIT",
6
6
  "author": "",