mars_nwe/mars-nwe
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases 2 Wiki Activity

docs: audit TTS endpoint coverage

Browse Source
This commit is contained in:
OpenAI
2026-06-02 13:36:47 +00:00
committed by Mario Fetka
parent a5a5d5b9e4
commit 1ca5d66432
2 changed files with 80 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
TODO.md
View File

@@ -176,9 +176,8 @@ Present in the code but not yet fully endpoint-audited:
property, set, password, queue, and management/admin subfunctions still need
the same PDF/WebSDK/include comparison in `src/nwbind.c` and the related
queue prehandlers.
- SDK `0x2222/34` / wire `0x22` TTS calls are present in `src/nwconn.c`;
their remaining state-changing layouts still need source comparisons beyond
the current availability/no-op note.
- SDK `0x2222/34` / wire `0x22` TTS calls are present in `src/nwconn.c` and
have been endpoint-audited as an unsupported/no-rollback compatibility group.
- SDK `0x2222/35` / wire `0x23` AFP calls are present in `src/nwconn.c`; AFP has
separate compatibility tests, but the NCP request-layout audit should still
be completed endpoint by endpoint.
@@ -939,20 +938,29 @@ Follow-up:
Current status:
- `NCP 0x22/0x00 TTS Is Available` reports the WebSDK-documented
unavailable status.
- `NCP 0x2222/34` / wire `0x22` is endpoint-audited in `src/nwconn.c`.
- `34/00 TTS Is Available` reports the WebSDK/NDK-documented unavailable
status by returning completion `0x00` and no reply payload.
- The SDK-listed through-3.x TTS subfunctions are documented inline:
`34/01` Begin Transaction, `34/02` End Transaction, `34/03` Abort
Transaction, `34/04` Transaction Status, `34/05`/`34/06` application
thresholds, `34/07`/`34/08` workstation thresholds, and `34/09`/`34/10`
transaction bits.
- MARS-NWE does not currently implement TTS rollback semantics, transaction
files, transaction status tracking, or the begin/end/abort transaction
state machine.
- Other TTS subfunctions remain unsupported instead of pretending to succeed
without real transaction tracking.
files, transaction status tracking, threshold state, or begin/end/abort
transaction state. The non-availability subfunctions intentionally return
`0xfb` instead of pretending to succeed.
- No SDK-listed through-3.x TTS subfunctions beyond `34/10` were found in the
NDK/Core-Protocols TTS table during this audit.
Follow-up:
- Implement TTS only if a concrete client requires it.
- Treat this as a real transaction subsystem, not as a completion-code shim:
the WebSDK TTS calls include begin/end/abort transaction, status, threshold,
and control/statistics operations.
the SDK calls require transaction numbering/status, rollback/backout,
threshold state, control flags, and interaction with logical/physical locks.
- If TTS is ever implemented, add tests that prove `34/02` returns a real
TransactionNumber and that `34/04` reports status for that number.
### AFP / Mac namespace backend

72
src/nwconn.c
View File

@@ -5813,18 +5813,68 @@ static int handle_ncp_serv(void)
case 0x22 : { /* Transaction Tracking System (TTS) calls */
int ufunc = (int) *requestdata;
/*
* WebSDK / headers:
* NCP 0x2222/34/00 TTS Is Available has no reply data.
* Its completion code is the status value: 0x00 means
* Transaction Tracking Unavailable, 0xfd means Disabled,
* and 0xff means Available. The SDK headers expose this
* as NWTTSIsAvailable().
* NCP 0x2222/34 Transaction Tracking System (TTS) group.
* The dispatcher passes requestdata[0] as SubFunctionCode
* and the remaining bytes as the subfunction payload. This
* code currently only answers the availability probe and
* intentionally rejects every state-changing or state-query
* request because MARS-NWE has no TTS rollback subsystem.
*
* MARS-NWE does not implement transaction tracking. Report
* the documented unavailable status for the availability
* probe, but keep the state-changing TTS subfunctions
* unsupported rather than pretending to begin, end, or abort
* transactions without rollback semantics.
* SDK / NDK subfunctions for the through-3.x-compatible TTS
* group:
*
* 34/00 TTS Is Available
* request: byte SubFunctionCode == 0
* reply: no reply payload
* completion is the result value: 0x00 unavailable,
* 0xfd disabled, 0xff available. MARS-NWE returns
* 0x00 to report that TTS is unavailable.
*
* 34/01 TTS Begin Transaction
* request: byte SubFunctionCode == 1
* reply: no reply payload.
*
* 34/02 TTS End Transaction
* request: byte SubFunctionCode == 2
* reply: long TransactionNumber (Hi-Lo).
*
* 34/03 TTS Abort Transaction
* request: byte SubFunctionCode == 3
* reply: no reply payload.
*
* 34/04 TTS Transaction Status
* request: byte SubFunctionCode == 4, then long
* TransactionNumber (Hi-Lo) at request offset 8.
* reply: no reply payload.
*
* 34/05 Get Application Thresholds and 34/07 Get
* Workstation Thresholds
* request: byte SubFunctionCode == 5 or 7
* reply: byte LogicalLockThreshold, byte
* PhysicalLockThreshold.
*
* 34/06 Set Application Thresholds and 34/08 Set
* Workstation Thresholds
* request: byte SubFunctionCode == 6 or 8, then byte
* LogicalLockThreshold and byte PhysicalLockThreshold.
* reply: no reply payload.
*
* 34/09 Get Transaction Bits
* request: byte SubFunctionCode == 9
* reply: byte ControlFlags. The NDK table prints this
* field at reply offset 9, but the only payload byte is
* ControlFlags after the normal reply header.
*
* 34/10 Set Transaction Bits
* request: byte SubFunctionCode == 10, then byte
* ControlFlags.
* reply: no reply payload.
*
* MARS-NWE returns 0xfb for all subfunctions except 34/00.
* That is deliberate: returning synthetic success for Begin,
* End, Abort, thresholds, status, or control bits would make
* clients believe transaction rollback is active when no
* transaction files, status tracking, or backout logic exists.
*
* Cross-check: lwared and the Rust nwserver code do not
* provide a fuller TTS transaction implementation to mirror.