Problem sending back replies to TCP client (on esp8266)...

I have almost completed a project for configuring a ESP-07 WiFi board via TCP.
I started out with the Arduino UART_TCP_Bridge example and then I added a second TCP server running on port 7777.
I can connect the client (a custom program on my PC) successfully to the TCP port 7777 and I can send config commands into the server and they are correctly read and processed. A reply is created in the processing function too.
I have added a lot of serial diagnostic messages at different points in the path of the request to see where it fails, but cannot find the cause...

So I need some pointers on how to properly send back a reply to a calling TCP client.

In my loop() function I have this (stripped down a bit):

void loop()
{
	  uint8_t i;
	  char buf[1024], cnfBuf[100];
	  unsigned int bytesAvail, bytesIn, cnfBytesAvail, cnfBytesIn, cnfBytesOut;
...
	  //check if there are any new Config clients
	  if (tcpConfigSrv->hasClient()) {
	    for (i = 0; i < MAX_CONF_CLIENTS; i++) {
	      //find free/disconnected spot
	      if (!tcpConfigClients[i] || !tcpConfigClients[i].connected()) {
	        if (tcpConfigClients[i]) tcpConfigClients[i].stop();
	        tcpConfigClients[i] = tcpConfigSrv->available();
	        SerialDebug.print("New Config client: "); SerialDebug.println(i);
	        continue;
	      }
	    }
	    //no free/disconnected spot so reject
	    WiFiClient tcpConfigClient = tcpServer->available();
	    tcpConfigClient.stop();
	  }

	  //--------------- check clients for data ---------------------------

	  // Check for Config data ------
	  for (i = 0; i < MAX_CONF_CLIENTS; i++) {
	    if (tcpConfigClients[i] && tcpConfigClients[i].connected()) {
	      //get data from the telnet client and push it to the Configuration function
	      while ((cnfBytesAvail = tcpConfigClients[i].available()) > 0) {
	        cnfBytesIn = tcpConfigClients[i].readBytes(cnfBuf, min(sizeof(cnfBuf), cnfBytesAvail));
	        if (cnfBytesIn > 0) {
	          SerialDebug.write(cnfBuf, cnfBytesIn); // <== This shows correct reception of cmd
	          ProcessConfigCall(cnfBuf, cnfBytesIn); // <== This function processes call correctly
	          delay(0);
	        }
	      }
	    }
	  }

	//Now check if there are config data to be returned
	//Send buffered data back to config clients
	for (i = 0; i < MAX_CONF_CLIENTS; i++) {
		if (tcpConfigClients[i] && tcpConfigClients[i].connected()) {
			//Now check if there are config data to be returned
			cnfBytesOut = strlen(cnftxbuf);
			if (cnfBytesOut>0) {
			  tcpConfigClients[i].write((uint8_t*)cnftxbuf, cnfBytesOut);
			  SerialDebug.print("Returning data: "); SerialDebug.println(cnftxbuf);
			  cnftxbuf[0] = 0; //Reset buffer after transmit
			}
			delay(0);
		}
	}

In my serial monitor I do see the "Returning data..." correctly:

Returning data: IP=192.168.211.1OK

But for some reason nothing seems to be sent to my client...
To check if it is possible to send back at all I had put the following into the receive code:

       if (cnfBytesIn > 0) {
         tcpConfigClients[i].write((uint8_t*)cnfBuf, cnfBytesIn); //<==Debug, does this reach the client?
         SerialDebug.write(cnfBuf, cnfBytesIn);
         ProcessConfigCall(cnfBuf, cnfBytesIn);
         delay(0);
       }

With this in place I see an echo of the command sent to the client coming back, so why does it not work sending back the processed reply instead?

	  char buf[1024]

Are you sure that the buffer is big enough? What configuration information requires a buffer that big? Do you have a stupidly long password?

	    //no free/disconnected spot so reject
	    WiFiClient tcpConfigClient = tcpServer->available();
	    tcpConfigClient.stop();

There are no available connections, so get an available one, and stop it. How is THAT supposed to work?

         delay(0);

The epitome of stupidity.

You might have better luck at http://snippets-r-us.com.

1. The size of the buf array is unchanged from the original serial bridge example I started from (obtained as an example inside Arduino IDE).

2. There is no password involved in this communication.

3. When I implemented the config server I simply copied the entire section from the serial bridge section.
   I do not have any idea how this really works...

4. Delay(0), why is this a stupidity? It can be seen in a lot of examples and I believe is there in order to yield to the "operating system" so that the watchdog timer does not trigger and resets the whole unit.

5. Connection check
   Again taken froim the original example, don't know how it is supposed to work..
   I have raised another thread in order to find out how I can detect that a client has actually disconnected.
   

6. Snippet too short?
   Well your quote surely is but in my post's first snippet I put the entire code of the loop pertaining to the config server...
   And added the part where I proved that the commands were there.

Anyway I should have come back here and reported that the issue is solved..