[Spread-users] Bug in SP_connect_timeout?

Arkady Lipovetsky arkady at peerapp.com
Thu Dec 8 02:43:38 EST 2016

Hi, guys I have encountered a BUG in spread user interface that is intended for asynchronous working (event system). The mechanism is implemented on "select" call, but this call has some limitation such as a max file descriptor that is 1024. The spread check this value and generate an error if file descriptor more than 1024. In my local version I has solved this issue by using epoll system call instead select. We are using a huge number for file descriptors, so if  number of used file descriptors is more than 1024 (it happens at spread reconnection time we get an Error). I checked all previous version and found that this BUG exists in all of them.


-----Original Message-----
From: Jan Moringen [mailto:jmoringe at techfak.uni-bielefeld.de] 
Sent: יום ג 06 דצמבר 2016 14:10
To: spread-users at lists.spread.org
Subject: [Spread-users] Bug in SP_connect_timeout?


I think I have found a small bug in SP_connect_timeout: after receiving the length of the authentication method list, the following code is executed to receive the list itself:

    ret = recv_nointr_timeout( s, auth_list, auth_list_len, 0, &time_out);

This works most of the time, but in my use-case, the authentication method list was broken up into multiple frames, resulting in this call receiving less than auth_list_len octets. Since ret is checked for errors but not short reads, the connection attempt failed.

Kind regards,

Spread-users mailing list
Spread-users at lists.spread.org

More information about the Spread-users mailing list