Network Protocol (v2)
  • 08 Mar 2021
  • 1 Minute to read
  • Dark
    Light
  • PDF

Network Protocol (v2)

  • Dark
    Light
  • PDF

Article Summary

Reference Documentation

This documentation is intended to describe the inner workings of the Inedo Agent, and does not provide any guidance on configuration or troubleshooting.

This protocol is intended for use over bidirectional TCP.

Handshake

Upon connection, a client submits the following 24-byte handshake to the server:

Byte OffsetTypeDescription
0GuidProtocol ID: 6CEBD24E-4AF7-4A13-B9AF-81D3DFC644BE
16int32Min supported Protocol Version: 1000
20int32Max supported Protocol Version: 2000

If the protocol ID is not valid, the server will immediately disconnect. Otherwise, the server responds with:

Byte OffsetTypeDescription
0int8Required encryption mode. May be:
  • 0: none
  • 1: SSL
  • 2: AES
1int8[16]AES initialization vector if using AES encryption
17/1int32Actual server protocol version
21/5int32Server version - [major].[minor].[build].[revision] (assembly version of server)

Note: AES initialization vector is only included if using AES encryption. {.info}

Note: Session ID may be used in a future version to support reconnecting after a dropped connection, but it is currently ignored. {.info}

Once connected, the server waits to receive a message from the connected client.

Client to Server Message

All client to server messages take the following form:

Byte OffsetTypeDescription
0int32Data length (length of Data field in bytes)
4int32Command
8bytesData

When using no encryption or SSL encryption, messages are sent in this format over TCP directly. When using AES encryption, the message looks like this:

Byte OffsetTypeDescription
0int32Encrypted data length (length of full encrypted message, including every field after this one)
4*int8[16]Initialization vector for next message
20*int32Command code
24*bytesData

*All fields after length are encrypted. Offsets are applicable after message has been decrypted

Server to Client Message

The server can send messages back to the client, with the following form:

Byte OffsetTypeDescription
0int32Data length (length of Data field in bytes)
4int32Command code
5bytesData

When using no encryption or SSL encryption, messages are sent in this format over TCP directly. When using AES encryption, the message looks like this:

Byte OffsetTypeDescription
0int32Encrypted data length (length of full encrypted message, including every field after this one)
4*int8[16]Initialization vector for next message
20*int32Command code
24*bytesData

*All fields after length are encrypted. Offsets are applicable after message has been decrypted


Was this article helpful?