Opened 14 years ago

Closed 12 years ago

#35 closed Bug / Defect (worksforme)

No magic limitation on socket size

Reported by: Samuli Seppänen Owned by:
Priority: major Milestone:
Component: Networking Version: OpenVPN 2.1.0 / 2.1.1 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

Hello,

i think this patch https://community.openvpn.net/openvpn/changeset/e2e10f8d7a4d9477a8e35d10df5f54885fe3c092 is a problem.

If we want to do a vpn transfer at 100mb/s or more, we need a big socket size. An userland process lag of 2 seconds cause a buffering in kernel socket of at least 200Mb (25MB).

So we need a value in configuration to set the socket size. Cool we have one! But a *magic* value limit the socket size to 1Mo. First issue, if this value is bad : no error / warning message is printed.

2 choices is binding us, change the magic value in socket.h to a biggest value. Equally magical. I think it's the system job to know the max hardware driven max socket size and not to openvpn program. kernel have max value and default value so not need to be checked.

A last point, this is not theorical request, this come from a use case trouble.

So i think we need to rollback this patch.

Change History (3)

comment:1 Changed 14 years ago by Samuli Seppänen

Posted to SF.net bug tracker by somebody (anonymous).

comment:2 Changed 13 years ago by David Sommerseth

I don't think that patch should be reverted, tbh. Rather beware that the default value for the send and receive buffers are 65535 bytes. The maximum limit is 1000000 bytes. It can be discussed though if that maximum limit is too restrictive.

The send and receive buffers are tunable via --sndbuf and --rcvbuf options.

comment:3 Changed 12 years ago by Samuli Seppänen

Resolution: worksforme
Status: newclosed
Note: See TracTickets for help on using tickets.