Hi Gert, > "--tcp-server" Yep, mean it, even poll doesn't used there. Have no any prio about it tho, just related thoughts.
-- Best Regards, Vladislav Grishenko > -----Original Message----- > From: Gert Doering <g...@greenie.muc.de> > Sent: Monday, October 5, 2020 10:28 PM > To: Vladislav Grishenko <themi...@yandex-team.ru> > Cc: 'Gert Doering' <g...@greenie.muc.de>; openvpn- > de...@lists.sourceforge.net > Subject: Re: [PATCH applied] Re: Speedup TCP remote hosts connections > > Hi, > > On Mon, Oct 05, 2020 at 10:22:43PM +0500, Vladislav Grishenko wrote: > > Perhaps same approach can be applied to server's tcp listening, would > > require testing of more management cases. > > There's two code paths here > > --tcp-server > > and > > --mode server + --tcp > > I think the "mode server" code path is already very quick (= if I test with your fast > TCP client, against a "git master" server, I get 0.16s connection setup time). This > is what people use on "more than one client" servers, so it's already fine. > > The "--tcp-server" code path is "point to point". Not sure we currently test this > at all (I have UDP p2p instance, but no TCP yet... seems I need to add one). This > might indeed be slow, I had a look at the > accept() path in socket.c recently and was wondering "how can this work at all?" > - but that's "socket.c" vs. "mtcp.c", I think. > > > Since this is somewhat of a niche case, I'd put that into the "2.6" bin :-) > - the other one, TCP on the client, is much more heavily used, so 2.5 > for that was appropriate. > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh Mistress > > Gert Doering - Munich, Germany g...@greenie.muc.de _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel