From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server-vie001.gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,URIBL_DBL_BLOCKED_OPENDNS, URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=new2025; t=1757165466; bh=du1mPisbfu7AG3MveoQjFZBpbqSUm8256BoKvHEMnfo=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding:Message-ID:Date:From: Reply-To:Subject:To:Cc:In-Reply-To:References:Resent-Date: Resent-From:Resent-To:Resent-Cc:User-Agent:Content-Type: Content-Transfer-Encoding; b=JQxswSIiCWh+kWSYQfkUjnrIIEmDKm7qXBNACnOLlm77PF1s4vpBp7lTD9nbKDBbb lXaf7SLUpOHZiu9DOtxwc2X0sIO7wdhDH1zkKCXHnSbAGCylJ50Qc2t9CN1hA31iDf eQHpfsS27zRtYB46Hn1w8avWlEA8NC49wT+zuLs3VOVana5hQ1kf8toDqrGW4Nmtm6 /o53JGyVzHnt68XNpi0FD1Rpj7qoJ/aPoSvKvm6txyls0d36NPRPd72i390gNxxSYJ s/sLomJcdUev252XXUcUsIx5f3i6QCMdgXCP4wRwO7sPGSqraM7u8EtWbqntSAIs2C A2zaFiDlV18uw== Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by server-vie001.gnuweeb.org (Postfix) with ESMTPSA id D575531279C9 for ; Sat, 6 Sep 2025 13:31:06 +0000 (UTC) Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-7704f3c46ceso2371384b3a.2 for ; Sat, 06 Sep 2025 06:31:06 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXQJCcbxb1i+hQOTqV4rzJQUHhQ4lLhtidVBhuzIQ1LhdDY8AcuszTYBkSwfKGXE99/pAMM@vger.gnuweeb.org X-Gm-Message-State: AOJu0YwMIUKPnl0y3TmV1y5/hhMJEJv4J8qP+7UfDXWkNCvxDJTMgNZ9 VT/HDYq0NAMMJD5HfcIfDbIOBFkdHtu1+28Y2dRRPRxHkdp/jWCiw4Lnk2Eaa2XJgj90+BbZs/J OjL4Zpope55fC4wKa1aJvmVque6/4Ikg= X-Google-Smtp-Source: AGHT+IFfxyORmqAHQVnTCCAsqgJ2HR3GPB6sX9NT9GWjOnE1ZkTFTb9HBILHa4XY5tuZzDD1RQjCu42XELkmkDVdIjY= X-Received: by 2002:a05:6a20:734b:b0:251:e18:bc9c with SMTP id adf61e73a8af0-253430ae21cmr3162454637.31.1757165465160; Sat, 06 Sep 2025 06:31:05 -0700 (PDT) MIME-Version: 1.0 References: <20250829075557.598176-1-reyuki@gnuweeb.org> <20250829075557.598176-3-reyuki@gnuweeb.org> In-Reply-To: From: Alviro Iskandar Setiawan Date: Sat, 6 Sep 2025 20:30:54 +0700 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXwibN2XleJ7GvZ_IN8FA_oCLJ_7aUgHqWClZkJuKqHJ5Cen125YXiBc0NQ Message-ID: Subject: Re: [PATCH gwproxy v8 2/2] gwproxy: refactor code base to add experimental raw DNS backend To: Ahmad Gani Cc: Ammar Faizi , "GNU/Weeb Mailing List" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: On Sat, Sep 6, 2025 at 7:59=E2=80=AFPM Ahmad Gani wrote: > So, what are our options in this case? Ok, good question. That's probably the most challenging part of this implementation. It will require careful planning to ensure that all edge cases are handled properly. My initial thought is, the most efficient data structure for this task would be an array of "struct gwp_conn_pair". Let's drop the atomic counter proposal. I suggest having thread-local incrementing counters. So the plan is, each thread has its own DNS resolver. That will simplify things a lot, because we don't need to worry about synchronization across threads. Each thread will have its own "struct gwp_conn_pair" array that maps the txid to your session. That also means, each thread can only have a max of 65536 concurrent connections. We can expand it by having more than one array. But I think that can be done later. Here's the initial plan (may still change as we go and discover more requirements): 1) Each thread has its own DNS resolver. 2) Each DNS resolver has: struct gwp_conn_pair *pairs[65536]; On a 64-bit machine, that's around 0.5MB per thread. On a 32-bit machine, that's around 0.25MB per thread. You may as well allocate it lazily by calling realloc() starting from a small number and keep reallocating as the number grows to keep the memory footprint low. 3) The array index will be the txid. 4) Each entry in the array will be a pointer to a struct gwp_conn_pair that contains the session information. But note that, since the lifetime of the "struct gwp_conn_pair" is now tied to both: 1) The SOCKS5 session, and 2) The DNS resolution query. You will need to make "struct gwp_conn_pair" refcounted to avoid use-after-free in case the DNS resolution query completes after the SOCKS5 session has been killed. I will think more about this and post something about it later when I have something better in my mind. Let me know your design if you have one too.