new_connected_socket failed; create udp_fd error

[kakadu1kakadu]

Hi, when I run the code for more than 1023 packets I face a problem with fd allocation, because the code opens a new socket for each new packet the client sends It prints 2 errors to the screen

new_connected_socket create udp_fd error

I wonder if that problem can be fixed by sending all packets from the same socket (port on the client), or the sockets need to be closed faster than 3 minutes after they are opened (the current situation). Can the option, --sock-buf 10240 (MAX buffer) somehow solve this problem

For English speaking user： https://github.com/wangyu-/UDPspeeder/wiki/Issue-Guide

中文用户请看： https://github.com/wangyu-/UDPspeeder/wiki/发Issue前请看 (否则Issue可能被忽略，或被直接关掉)

[Cyber-code]

Did you solve the problem ? I have a the same

[wangyu-]

hi, could you explain how to re-produce the problem?

possible reason:

if the 1023 packets you send to UDPspeeder were via the same port, UDPspeeder will only create one socket.

But if you are sending the 1023 packets with 1023 different ports, UDPspeeder will treat each packet from a new port as a seperate "connection", it will created a connected socket for each "connection"

or the sockets need to be closed faster than 3 minutes after they are opened (the current situation).

you can decrease those values in common.h:

const u32_t conv_timeout=180000;    //how fast does connection timeout
const u32_t conv_clear_interval=1000;  //how often to garbage collection timeouted connections
const int conv_clear_ratio=30;    //not so easy to explain, you can set it to 1 for fastest garbage collection

(currently there are no run-time parameters to change them, you have to re-compile. I will consider make them run-time parameters in furture )

maybe an easier solution is to increase the fd limit by ulimit?

[wangyu-]

I have some further thought about the problem.

I wonder if that problem can be fixed by sending all packets from the same socket (port on the client)

This problem can't be simply fixed by sending all packets from the same socket (using unconnected socket). UDPspeeder is designed to support both short term udp "connection" and long term udp "connection". For long term "connection", the data is needed to be sent from same port as the first packet of the "connection", and it's necessary to guarentee no data from other "connection" is sent via the same port. So it's necessary to ensure the port is occupied by some mechanism. Connected socket is the only way (I know on POSIX) to occupy a port.

On modern linux fd is a pretty cheap resource, and it's not a rare case for a server to handle more than 10k of connections. So the default value of fd limited (usually 1024) is too low for a machine used as server. I think the best way to solve this problem is to increase the fd limit.

[Cyber-code]

Hi ! Sorry for not responding quickly.

Yea I resolve my problem with that : I was creating multiple socket each time I wanted to send data, and in Linux, a socket it’s a file descriptor, I quickly arrive to the limit.

I resolve with creating a global socket and sending with the same : only one fd for my program.

I have a similar issue with file descriptor and make the connection with this problem. Of course, rise the limit it’s a solution but i think it’s preferable to see if it’s not a coding problem : maybe the user will not think to increase this number.

Thanks for your Amazing software and for you quick response about it !

[tosiara]

This happens when you point UDPspeeder service to UDPspeeder client instead of a local service, like: server: ./speederv2 -s -l 192.168.122.172:5800 -r 192.168.122.98:5800 client: ./speederv2 -c -l 192.168.122.98:5800 -r 192.168.122.172:5800

You should get this log:

[2021-01-27 12:15:38][INFO]argc=6 ./speederv2 -s -l 192.168.122.172:5800 -r 192.168.122.98:5800 
[2021-01-27 12:15:38][INFO]parsing address: 192.168.122.172:5800
[2021-01-27 12:15:38][INFO]its an ipv4 adress
[2021-01-27 12:15:38][INFO]ip_address is {192.168.122.172}, port is {5800}
[2021-01-27 12:15:38][INFO]parsing address: 192.168.122.98:5800
[2021-01-27 12:15:38][INFO]its an ipv4 adress
[2021-01-27 12:15:38][INFO]ip_address is {192.168.122.98}, port is {5800}
[2021-01-27 12:15:38][INFO]jitter_min=0 jitter_max=0 output_interval_min=0 output_interval_max=0 fec_timeout=8 fec_mtu=1250 fec_queue_len=200 fec_mode=0
[2021-01-27 12:15:38][INFO]fec_str=20:10
[2021-01-27 12:15:38][INFO]fec_inner_parameter=1:10,2:10,3:10,4:10,5:10,6:10,7:10,8:10,9:10,10:10,11:10,12:10,13:10,14:10,15:10,16:10,17:10,18:10,19:10,20:10
[2021-01-27 12:15:38][INFO]now listening at 192.168.122.172:5800
[2021-01-27 12:15:44][INFO]new connection from 192.168.122.98:38474
[2021-01-27 12:15:44][INFO][192.168.122.98:38474]new conv b10811fa,fd 6 created,fd64=4294967395
[2021-01-27 12:15:44][INFO][192.168.122.98:38474]new conv ba0acdb,fd 7 created,fd64=4294967396
[2021-01-27 12:15:44][INFO][192.168.122.98:38474]new conv 95125afa,fd 8 created,fd64=4294967397
[2021-01-27 12:15:44][INFO][192.168.122.98:38474]new conv 5d75fa10,fd 9 created,fd64=4294967398
...
[2021-01-27 12:15:53][INFO][192.168.122.98:38474]new conv 75d11f76,fd 1021 created,fd64=4294968410
[2021-01-27 12:15:53][INFO][192.168.122.98:38474]new conv 7713928e,fd 1022 created,fd64=4294968411
[2021-01-27 12:15:53][INFO][192.168.122.98:38474]new conv 7a40fdf6,fd 1023 created,fd64=4294968412
[2021-01-27 12:15:53][WARN][192.168.122.98:5800]create udp_fd error
[2021-01-27 12:15:53][WARN][192.168.122.98:38474]new_connected_socket failed