From 4ad22ebe0be45d794921e68178c4885f9134ddab Mon Sep 17 00:00:00 2001 From: Christian Pointner Date: Sat, 9 Sep 2017 03:38:19 +0200 Subject: improved wording for handling of encrypted/plain packet --- NOTES | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) (limited to 'NOTES') diff --git a/NOTES b/NOTES index e125609..f9c509d 100644 --- a/NOTES +++ b/NOTES @@ -94,17 +94,18 @@ Packet Handling (Marshal/Unmarshal): encode/decode using BigEndian.(Put)?Uint(16|32). All of this shouldn't need any mallocs and would therefor be pretty fast. - EncryptedPacket has function DecryptAndVerify() which returns a PlainPacket. - PlainPacket has a EncryptAndAuthenticate() which returns an EncryptedPacket. - The implicit copy operations of the crypto functions are free because the - encrypt/decrypt process needs to read and write the memory anyway and it makes - no difference whether the destination is the same or some other memory area. + EncryptedPacket has function VerifyAndDecrypt() which takes a PlainPacket to + store the result. PlainPacket has a EncryptAndAuthenticate() which takes an + EncryptedPacket to store the result. The implicit copy operations of that + crypto functions are free because the encrypt/decrypt process needs to read + and write the memory anyway and it makes no difference whether the destination + is the same or some other memory area. Conclusion: Any packet handling goroutine holds one EncryptedPacket and one PlainPacket. Idea: Have NumCPU goroutines for receving and NumCPU goroutines for sending. - Receiving: UPD --> decrypt&verify --> tun/tap + Receiving: UPD --> verify&decrypt --> tun/tap Sendung: tun/tap --> encrypt&auth --> UDP -- cgit v1.2.3