SN Server implementation

[jing-git]

I'm reading the code related to SN Server recently, and I would like to record its implementation here.

1. The main content of the SN protocol

1.1 What is SN?

SN stands for SuperNode, which is deployed on machines with fixed public network addresses. It is used to discover the NAT addresses mapped by devices passing through NAT, query device information, and assist in NAT punching.
The program that provides SN service is called sn-miner, and the program that uses SN service is called sn-client. The sn-client will periodically send information to the sn-miner to notify its device_id and the outermost NAT public network address.

1.2 The interaction process of the SN protocol

1.2.1 Ping

The sn-client periodically sends Ping information to sn-miner for keep-alive. The sn-miner will cache the data (DEVICE_ID, NAT_WAN_ADDRESS, CACHE_TIMEOUT, etc.) into the peers table and provide a basis for other devices to query information.

1.2.2 Call/Called

When LN needs to communicate with RN, LN only knows RN's device_id. At this time, LN sends a Call protocol packet to sn-miner, and sn-miner returns RN's peer information to LN. At the same time, sn-miner sends a Called packet to RN, informing it that LN wants to communicate with it. After RN responds with CalledResp, it sends data to LN's NAT address, establishes a Tunnel, and enters the NAT penetration process.

1.3 Connectivity of Tunnel in different NAT environments

1.4 Header structure of the SN protocol

pub struct SnPing {
    pub protocol_version: u8, 
    pub stack_version: u32, 
    pub seq: TempSeq,
    pub sn_peer_id: DeviceId, //SN's device id
    pub from_peer_id: Option<DeviceId>, //sender's device id
    pub peer_info: Option<Device>, //sender's device info
    pub send_time: Timestamp,
    pub contract_id: Option<ObjectId>,
    pub receipt: Option<ReceiptWithSignature>,
}

pub struct SnPingResp {
    pub seq: TempSeq,
    pub sn_peer_id: DeviceId,
    pub result: u8,
    pub peer_info: Option<Device>,
    pub end_point_array: Vec<Endpoint>, //sender's NAT addresss info
    pub receipt: Option<SnServiceReceipt>,
}

pub struct SnCall {
    pub protocol_version: u8, 
    pub stack_version: u32, 
    pub seq: TempSeq,
    pub sn_peer_id: DeviceId,
    pub to_peer_id: DeviceId,
    pub from_peer_id: DeviceId,
    pub reverse_endpoint_array: Option<Vec<Endpoint>>,
    pub active_pn_list: Option<Vec<DeviceId>>,
    pub peer_info: Option<Device>,
    pub send_time: Timestamp,
    pub payload: SizedOwnedData<SizeU16>,
    pub is_always_call: bool,
}

pub struct SnCallResp {
    pub seq: TempSeq,
    pub sn_peer_id: DeviceId, //LN's device id
    pub result: u8,
    pub to_peer_info: Option<Device>,
}

pub struct SnCalled {
    pub seq: TempSeq,
    pub sn_peer_id: DeviceId,
    pub to_peer_id: DeviceId,
    pub reverse_endpoint_array: Vec<Endpoint>,
    pub active_pn_list: Vec<DeviceId>,
    pub peer_info: Device,
    pub call_seq: TempSeq,
    pub call_send_time: Timestamp,
    pub payload: SizedOwnedData<SizeU16>,
}

pub struct SnCalledResp {
    pub seq: TempSeq,
    pub sn_peer_id: DeviceId,
    pub result: u8,
}

2. SN Miner's modular division

2.1 Keystore

Cache the AESKey and MixHashKey corresponding to device_id, encrypt and decrypt data packets to ensure the security of communication data.

2.2 PeerManager

Cache the device information and WAN address information corresponding to device_id, which are regularly reported through the device's SN Ping.

2.3 CallStub

When SN receives a Call request from LN, it will send the corresponding Called to RN to inform RN that NAT Punching is required. The call_stub is used to record existing Calls to prevent duplicate Called requests.

2.4 ResendQueue

The Called packet sending queue will keep resending these data to RN until a corresponding CalledResp is received. And the maximum number of resend is 5, the resend interval is 200ms

2.5 Timer

(1) Check how long sn-client has not pinged keep-alive. If the time exceeds the client_ping_timeout (300s), remove it from the peers HashMap and reset the previously agreed key information.
(2) Check the resend_queue queue, resend the Called packets, and clear packets that have been resent too many times.
(3) Check the call_stub queue and clear data that has been cached for more than 1 minute.
(4) The time interval for checking: 100ms.

2.6 NetListener

The network interface module, supports UDP and TCP under IPv4 and IPv6, receives data packets, and processes them through the function process_pkg().
Currently supported commands include: Exchange、SnPing、SnCall、SnCalledResp.

3. SN's internal data flow