title: Server crashes when it receives a request while it is already processing a request
body: <p>The server code I have works fine as long as only one request is being sent at a time. The data flows like this: The client does something, like click a button, and data is sent to the server. A header of type <code>uint16_t</code> is prepended to this data so that the server knows how many bytes out of the bytes available to read for this one request - a solution I thought would fix the problem I'm having. On the server, I connect the <code>readyRead</code> signal from <code>QTcpSocket</code> to a function that reads the header like this:</p>
  
  <pre><code>void Server::getHeader(){    
      QTcpSocket *client = qobject_cast&lt;QTcpSocket *&gt;(sender());
          if (!client)
              return;
  
      forever {
          int N = sizeof(uint16_t);
          qint64 bytes = client-&gt;bytesAvailable();
          if (bytes &lt; N) break;
          QByteArray buf = client-&gt;read(N);
          emit hasData(buf, client); //contains the number of bytes in the stream for this request and a reference to the current client
      }
  }
  </code></pre>
  
  <p>The <code>hasData</code> signal will trigger a function that will do the same thing the <code>getHeader</code> function does, but will wait for <code>bytes</code> number of bytes to be available instead of <code>sizeof(uint16_t)</code> bytes to be available. Once it sees that the desired number of bytes are available, it reads that many bytes from the stream and stores them in a <code>char[]</code>, then sends it to a function which makes sense of the data (where the problem occurs) like this:</p>
  
  <pre><code>void Server::handleConnection(std::string serverReceiveBuf, QTcpSocket *client){
      receivedData data; //a struct that organizes the data to be easily readable by a human
      QString stringBuilder;
      try{
          data.activityID = serverReceiveBuf.at(0);
          data.stringCount = serverReceiveBuf.at(1);
          int i,
              j = 2, //placeholder for next slot to be used in the receive buffer
              k = 0;
          for (i = 0; i &lt; data.stringCount; i++){ //while there are strings whose lengths we need to document
              data.stringLength.insert(i, serverReceiveBuf.at(2+i));
              j++;
          }
          while(k &lt; data.stringCount){ //while there are strings in the buffer to be put into the data structure
              i = 0;
              while(i &lt; data.stringLength.at(k)){ //while there are characters in the buffer to be built into a string
                  stringBuilder.append(serverReceiveBuf.at(j));
                  j++;
                  i++;
              }
              //we have assembled a string from chars in the buffer
              //now we put them into the struct
              data.stringData &lt;&lt; stringBuilder;
              stringBuilder = ""; //empty string builder for next string.
              k++;
          }
      }
      catch(std::exception e){
          qDebug() &lt;&lt; "[" &lt;&lt; currentTime() &lt;&lt; "] " &lt;&lt; "An undefined buffer error occurred.";
      }
  
      //Handle based on activity ID
  }
  </code></pre>
  
  <p>I put this code into a try/catch to prevent the server from crashing. It's not meant to be descriptive right now. If I take it out, the server will crash as soon as I try to access data that should be in <code>serverReceiveBuf</code> - the string of characters read from the stream of available bytes - because it's empty. With the try/catch block, any requests sent while one was still processing are just ignored and the error message is display on the server console.</p>
  
  <p>Now here's the frustrating part: When I try to step through the code with the debugger, it works. Presumably because the request is finished processing by the time the debugger goes back to handle the second request. I thought the requests were supposed to be queued up, but apparently not. Is there something special I have to do to force queuing of data so that I can ensure that the current request is processed before trying to handle the next one?</p>