net: add setTypeOfService and getTypeOfService to Socket

[amyssnippet]

this PR implements socket.setTOS(tos) and socket.getTOS() in net.Socket. it needed this to support DSCP tagging (QoS) for traffic prioritization, which wasn't previously exposed in the JS API. for the implementation:

• I added the logic in tcp_wrap.cc to attempt IP_TOS first, and fallback to IPV6_TCLASS if that fails. This handles both IPv4 and IPv6 sockets automatically without needing a separate flag.
• Windows returns UV_ENOSYS for now since the headers/implementation differ there.
• Added a new test file (test-net-socket-tos.js) to verify input validation and ensure the values are actually set on supported platforms.

Fixes: #61489

[nodejs-github-bot]

Review requested:

• @nodejs/net

[mcollina]

Good work. Can you add the documentation?

[amyssnippet]

Thanks @mcollina , is this ready to be merged? Please let me know if there is anything else you need me to adjust.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71012/

[ronag]

@mcollina I'm confused by the CI failures. Any ideas? Or just flaky?

[amyssnippet]

@amyssnippet: based on your solution I assume that libuv doesn't have an api for this... maybe would be an idea to open an issue over there as well?

i guess you are right @ronag
i read this https://docs.libuv.org/en/v1.x/guide/networking.html and found out there is missing API we need and thats why i was using raw setsockopt calls on the file descriptor.
Since getting a new feature into libuv and waiting for it to roll into Node.js would take a significant amount of time, could we land this implementation now to unblock the feature for users?
we need to add a feature request upstream in the libuv repo to add proper uv_tcp_set_tos API, and we can refactor this code to use that API once it is available.
rn i have done the #ifdef things, which is temp and pragmatic way, if we have to work on this properly, then we should consider contributing libuv.
what are your thoughts??

[amyssnippet]

and also i have observed some flaky ci tests here, should i report them as issues? or just paste them here so the internal team fixed them??

[amyssnippet]

libuv/libuv#2536
I found someone tried back in 2019. but got stalled for 5 years, but waiting for an upstream API seems risky.
By landing this setsockopt implementation in Node.js now, we unblock high-performance media applications immediately. should we open a new issue in libuv to revive the discussion, but I strongly believe we shouldn't block this PR on it.

[amyssnippet]

@ronag after inspecting some of errors in ci, i rolled some changes, kindle approve the ci once again so i can futher improve the checks

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71046/

[anonrig]

What does TOS stand for?

[ronag]

What does TOS stand for?

https://en.wikipedia.org/wiki/Type_of_service

[addaleax]

Our API names in Node.js are generally more verbose than the corresponding OS APIs – would there be anything speaking against calling these socket.getTypeOfService() and socket.setTypeOfService()?

[amyssnippet]

that makes sense and i agree to that, i will update to use full names

[amyssnippet]

@addaleax i have used full names now, check the latest changes

[addaleax]

I wouldn't say this needs to block this PR, but upstreaming these additions to https://github.com/libuv/libuv might be a good follow-up change

[amyssnippet]

even i was thinking the same, if internal members of nodejs will work and do the changes over there to libuv, then additions will be fast, rather than i do.

[santigimeno]

If you can open an issue there pointing to this PR, that will help and maybe someone picks it up.

[amyssnippet]

@santigimeno i already made an issue there, and a member of libuv is working on that, untill that, we could make a todo here in the cpp code to track the isssue and its relevant pr, and will update the libuv api, once it is rolled out. i looked a long on recent issues, prs whch got merged and i saw that it took a lot of time, but as we need to roll out this feature soon in the next minor version, we could consider forward looking at this pr so that we could easily bring the feature

[codecov]

Codecov Report

❌ Patch coverage is 54.62185% with 54 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.88%. Comparing base (5d39030) to head (c39d13e).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
src/tcp_wrap.cc	48.33%	18 Missing and 13 partials ⚠️
lib/net.js	61.01%	23 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #61503      +/-   ##
==========================================
- Coverage   89.82%   88.88%   -0.94%     
==========================================
  Files         667      672       +5     
  Lines      203693   203928     +235     
  Branches    39163    39129      -34     
==========================================
- Hits       182963   181259    -1704     
- Misses      13061    14933    +1872     
- Partials     7669     7736      +67     

Files with missing lines	Coverage Δ
src/tcp_wrap.h	71.42% <ø> (ø)
lib/net.js	93.67% <61.01%> (-1.62%)	⬇️
src/tcp_wrap.cc	69.68% <48.33%> (-4.93%)	⬇️

... and 121 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[amyssnippet]

@ronag kindly approve once again, i fixed the issue related to win vs2022 build error on my win laptop, and also i tested it here. i guess it should work, rest the rhel and linuxone test failures are flaky, i confirmed it by looking the console logs.

also i added a todo for the libuv in future. as i saw it will take time for the required api in the libuv.

libuv/libuv#5011

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71060/