Class TjsTcpNetConn

constructor

• new TjsTcpNetConn(
      conn: Connection,
      bring_your_own_buffer?: Uint8Array<ArrayBufferLike>,
  ): TjsTcpNetConn

  Parameters

  • conn: Connection
  • Optionalbring_your_own_buffer: Uint8Array<ArrayBufferLike>

  Returns TjsTcpNetConn

Readonlysize

read

• read(): Promise<NetConnReadValue>

  read the incoming data from the connection into a Uint8Array buffer, and get the address from which the message came from.

  if a readable data is already available, returned value will be of the NetConnReadValue kind, but if it isn't immediately available, a Promise to NetConnReadValue will be returned. this way, you can operate in both, immediate synchronous mode (for tasks, such as polling), or in asynchronous mode (for situations where you are anticipating a message).

  the awaitable NetConnReadValue value is a 2-tuple consisting of the Uint8Array buffer that's read, and the NetAddr from which the message originates from.

  it is possible for a read to successfully return with a buffer of zero bytesize, because it would indicate that a zero sized packet was received, which is different from not receiving any packets.

  TODO: what about partial packet? should the NetConn interface demand that they be joined before being presented by this interface? or should we allow the implementations to return data as it comes in?

  TODO: actually, I think it would be better to define this in a way that is intentionally blocking when awaited, rather than saying that it may return undefined when it hasn't received any messages.

  TODO: I just figured out that tcp, unlike udp, is stream-based. meaning that if a client sends us 2 tcp messages, they will be concatenated back to back. and if our internal read buffer is large enough, it will consume/contain both messages, with no segmentationg.

  Returns Promise<NetConnReadValue>

send

• send(buffer: Uint8Array, addr?: NetAddr): Promise<number>

  send the contents of the array buffer to a host with the addr network-address, over your connection.

  resolves to the number of bytes written. though it is kind of pointless given the TODO conundrum below:

  TODO: what should we do about input buffers that are not entirely sent in a single packet? should the implementation loop until all of it has been sent? or should it be up to the user of this interface to do that on their own?

  for now, I will enforce the rule that the send method must completely send the buffer before resolving its promise. it really makes things simpler for the end user, and it only adds one line of code for underlying implementations that do not necessarily send their buffer all in one go.

  Parameters

  • buffer: Uint8Array
  • Optionaladdr: NetAddr

  Returns Promise<number>

close

• close(): void

  closes the connection on your local device to free up resources.

  Returns void