Optional
codeOptional
logger?: LoggerOptional
reasonReadonly
[initProtected
_readProtected
_writeReadonly
closedPResolved when the stream has been completely closed (both readable and writable sides).
Protected
codeProtected
connectionReadonly
encodedReadonly
initiatedProtected
loggerReadonly
readableErrors:
.cancel(reason)
Protected
readableProtected
readableProtected
readableProtected
reasonProtected
Optional
rejectOptional
reason: anyProtected
Optional
rejectOptional
reason: anyProtected
resolveProtected
Optional
resolveProtected
Optional
resolveReadonly
streamReadonly
writableErrors:
.cancel(reason)
or .abort(reason)
Protected
writableProtected
writableWhether the stream has been completely closed (both readable and writable sides).
Returns connection data for the connection this stream is on.
Returns true if the readable has closed.
Returns true if the writable has closed.
Will trigger the destruction of the WebSocketStream
if the readable or writable haven't closed, yet they will be forced
closed with reason
as the error.
If streams have already closed then this will do nothing.
This is synchronous by design but cancelling will happen asynchronously in the background.
This ends up calling the cancel and abort methods. Those methods are needed because the readable and writable might be locked with a reader and writer respectively. So we have to cancel and abort from the "inside" of the stream. It's essential that this is synchronous, as that ensures only one thing is running at a time. Note that if cancellation fails...
Calling this will lead an asynchronous destruction of this WebSocketStream
instance.
This could throw actually. But cancellation is likely to have occurred.
Optional
reason: anyProtected
handleProtected
handleProtected
handleWe expect WebSocket stream error in 2 ways. WebSocket stream closure of the stream codes. On read side On write side We are able to use exception classes to distinguish things Because it's always about the error itself!A Note that you must distinguish between actual internal errors, and errors on the stream itself
Protected
readableProtected
readableProtected
readableThis method can be arrived top-down or bottom-up:
If force is true then this will cancel readable and abort writable. If force is false then it will just wait for readable and writable to be closed.
Unlike WebSocketConnection, this defaults to true for force.
Optional
force?: booleanOptional
reason?: anyProtected
streamProtected
writableProtected
writableProtected
writableProtected
writableGenerated using TypeDoc
Events: