potential block when using proxy protocol

[robklg]

In the proxy loop (ftpserver.rs), the function get_peer_from_proxy_header is called which blocks until the proxy header has completely been read. When for any reason this happens, new connections can not be accepted.

There are several angles to solve this that I've discussed and came up with together with @hannesdejager :

• replace incoming connection handler with one that calls get_peer_from_proxy_header as well
• spawn get_peer_from_proxy_header() in a async task, and use a channel to pass on the connection information + tcp stream back to the proxy loop
• spawn get_peer_from_proxy_header() in a async task, and add this task to a specific task queue, that can then be watched from within the select!
• spawn the hole incoming.next() arm in an async task, but that will require a concurrent hashmap to replace the current normal hashmap, including a performance penalty

In addition, a timeout must be introduced to make sure we close the connection if we do not receive the complete proxy header within x amount of time.

[Nigma1337]

I'm currently hitting this issue, when spawning unftp behind a digital ocean load balancer with proxy protocol enabled.

I'll get a connection, which will permanentely block any other connections. Seems like getting peer never ends.

Do you know about any work around, or is there something i can do to help finishing #209 ?

[robklg]

Hi @Nigma1337. Thank you for reaching out and offering to help. I'm sorry you run into this. I'm now working on a fix, and we intend to build a release this weekend. I hope and expect this fix to be in it. I'll keep you posted.

[Nigma1337]

Awesome! Apperciate it alot.

[hannesdejager]

Fixed in v0.18.6