-
Notifications
You must be signed in to change notification settings - Fork 214
Description
IXWebSocket/ixwebsocket/IXWebSocketTransport.cpp
Line 1067 in 679ce51
| _rxbuf.insert(_rxbuf.end(), _readbuf.begin(), _readbuf.begin() + ret); |
| _rxbuf.erase(_rxbuf.begin(), _rxbuf.begin() + ws.header_size + (size_t) ws.N); |
The way the code is using std::vector for the receive buffer with data being added at the end and removed from the front creates a time complexity bug. When erasing at the front, vector::erase is O(N) where N is the size of the whole vec, not the size of the packet data being erased. That means that dequeuing all packets is actually O(N^2)
If for whatever reason the receive buffer grows big enough, the time to dequeue one packet can exceed the time to receive one packet at which point it's a downward spiral that cannot be recovered (the process will grind to a halt).
This is not just theoretical, I experienced it in production.
The issue can be fixed by using a different datastructure for the receive buffer, such as std::deque.