Hacer que el receptor envíe un acuse de recibo es la mejor manera, incluso si "se siente incómodo". Recuerde que IP puede dividir sus datos en varios paquetes y volver a ensamblarlos, y esto podría hacerse varias veces a lo largo de una transmisión si varios enrutadores en el camino tienen diferentes MTU, por lo que su concepto de "un paquete" y TCP pueden no estar de acuerdo.
Es mucho mejor enviar su "paquete", ya sea una cadena, un objeto serializado o datos binarios, y hacer que el receptor haga las comprobaciones necesarias para que esté allí, y luego envíe un acuse de recibo.
El TCP de envío sabe cuándo el otro extremo reconoce los datos, pero la única razón por la que lo hace es para saber cuándo puede descartar los datos (porque otra persona ahora es responsable de llevarlos a la aplicación en el otro lado). ).
Por lo general, no proporciona esta información a la aplicación de envío porque (a pesar de las apariencias) en realidad no significaría mucho a la aplicación de envío. El reconocimiento no significa que la aplicación receptora haya obtenido los datos y haya hecho algo sensato con ellos; todo lo que significa es que el TCP emisor ya no tiene que preocuparse por ello. Los datos aún podrían estar en tránsito, dentro de un servidor proxy intermedio, por ejemplo, o dentro de la pila TCP receptora.
"Datos recibidos correctamente" es realmente un concepto de nivel de aplicación; lo que significa varía según la aplicación (por ejemplo, para muchas aplicaciones solo tendría sentido considerar los datos "recibidos" una vez que se hayan sincronizado con el disco en el receptor). lado). Eso significa que debe implementarlo usted mismo, porque como desarrollador de la aplicación, usted es realmente el único en posición de saber cómo hacerlo de manera sensata para su aplicación.