Opened 4 years ago

Closed 2 years ago

#35 closed Bug / Defect (worksforme)

No magic limitation on socket size

Reported by: samuli Owned by:
Priority: major Milestone:
Component: Networking Version: 2.1.0 / 2.1.1
Severity: Not set (if unsure, select this one) 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 4 years ago by samuli

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

comment:2 Changed 3 years ago by dazo

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 2 years ago by samuli

  • Resolution set to worksforme
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.