Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support needed in IO::Socket::INET for SO_SNDBUF and SO_RCVBUF [rt.cpan.org #52166] #17461

Open
toddr opened this issue Apr 19, 2018 · 0 comments
Labels
dist-IO issues in the dual-life blead-first IO distribution Feature Request

Comments

@toddr
Copy link
Member

toddr commented Apr 19, 2018

Migrated from rt.cpan.org#52166 (status was 'new')

Requestors:

Attachments:

From [email protected] on 2009-11-29 07:41:35:

The Linux tcp(7) man page says in part:

The maximum sizes for socket buffers declared via the SO_SNDBUF and
SO_RCVBUF mechanisms are limited by the global net.core.rmem_max
and net.core.wmem_max sysctls. ... On individual connections, the
socket buffer size must be set prior to the listen() or connect()
calls in order to have it take effect. 

This last sentence means that the IO::Socket::INET constructor must 
provide options to set the send and receive buffers if they are to 
be controllable, since the constructor does not return until after 
the listen() or connect() call has already been made.

I propose that two new options be added to the constructor:

    SendBuf => $send_buffer_size
    RecvBuf => $recv_buffer_size
    
so that these values can be set when the socket is created.

The attached INET.pm.patch provides this capability.


      
@toddr toddr transferred this issue from Dual-Life/IO Jan 20, 2020
@toddr toddr added Needs Triage dist-IO issues in the dual-life blead-first IO distribution labels Jan 20, 2020
@xenu xenu removed the Severity Low label Dec 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dist-IO issues in the dual-life blead-first IO distribution Feature Request
Projects
None yet
Development

No branches or pull requests

3 participants