Previously, only one client packet could be processed in a udp stream session even though multiple response packets were supported. Now multiple packets coming from the same client address and port are delivered to the same stream session. If it's required to maintain a single stream of data, nginx should be configured in a way that all packets from a client are delivered to the same worker. On Linux and DragonFly BSD the "reuseport" parameter should be specified for this. Other systems do not currently provide appropriate mechanisms. For these systems a single stream of udp packets is only guaranteed in single-worker configurations. The proxy_response directive now specifies how many packets are expected in response to a single client packet.
Previously, ngx_event_recvmsg() got remote socket addresses after creating the connection object. In preparation to handling multiple UDP packets in a single session, this code was moved up.
On Linux recvmsg() syscall may return a zero-length client address when receiving a datagram from an unbound unix datagram socket. It is usually assumed that socket address has at least the sa_family member. Zero-length socket address caused buffer over-read in functions which receive socket address, for example ngx_sock_ntop(). Typically the over-read resulted in unexpected socket family followed by session close. Now a fake socket address is allocated instead of a zero-length client address.
Negative times can appear since workers only update time on an event loop iteration start. If a worker was blocked for a long time during an event loop iteration, it is possible that another worker already updated the time stored in the node. As such, time since last update of the node (ms) will be negative. Previous code used ngx_abs(ms) in the calculations. That is, negative times were effectively treated as positive ones. As a result, it was not possible to maintain high request rates, where the same node can be updated multiple times from during an event loop iteration. In particular, this affected setups with many SSL handshakes, see http://mailman.nginx.org/pipermail/nginx/2018-May/056291.html. Fix is to only update the last update time stored in the node if the new time is larger than previously stored one. If a future time is stored in the node, we preserve this time as is. To prevent breaking things on platforms without monotonic time available if system time is updated backwards, a safety limit of 60 seconds is used. If the time stored in the node is more than 60 seconds in the future, we assume that the time was changed backwards and update lr->last to the current time.
The value is no longer guaranteed to be based on milliseconds elapsed since Epoch.
The bug in question was fixed in glibc 2.3.2 and is no longer expected to manifest itself on real servers. On the other hand, the workaround causes compilation problems on various systems. Previously, we've already fixed the code to compile with musl libc (fd6fd02f6a4d), and now it is broken on Fedora 28 where glibc's crypt library was replaced by libxcrypt. So the workaround was removed.