How to flush/push outbound data using FSocket API (HELP ME FLUSH)

I’ve been developing a plugin using the FSocket API, and I’ve come to a point where when I want my UE4 client to send the outbound data present in the socket’s output stream buffer, that I need to close the socket itself to flush/push the data. I would prefer to close the output stream independent of the input stream as the client needs to receive a response from the server.

I would like to have the FSocket in UE4 to accomplish these tasks in order

Desired Implementation:
1: UE4 Client - Send Data to External Server
2: UE4 Client - Close Output Stream, pushing data to server
3: External Server - Receives data from UE4 Client
4: External Server - Send data to UE4 Client
5: UE4 Client - Receive Data from External Server
6: UE4 Client - Close Input Stream

The problem existing in that sending data in step two, I’ve found no way of closing the output stream in an FSocket independent of the input stream, and instead have only managed to send data when closing the FSocket itself. An example of my implementation working is

Working Implementation:
1: External Server - Send Data to UE4 Client
2: UE4 Client - Receives data from External Server
3: UE4 Client - Sends data to External Server
4: UE4 Client - Closes FSocket
5: External Server - Receives Data from UE4 Client

The above implementation works as intended, but I require the client to be the first to send, and last to receive the data with the server, so besides closing the FSocket I need a way of flush the output stream’s buffer.

I was just notified by a helpful individual about different ways to go about solving this problem, I’ll post my results when I implement it, though it does sound like an effective solution to my network implementation problem.

“Streaming sockets can’t be flushed/closed independently of direction of data flow (in/out). Datagram sockets could be, but it would be kind of cumbersome to do that.
If you are planning on putting this in a datacenter somewhere, then I’d switch to HTTP rather than raw socket usage. This will give you the most options for building out a scalable backend service. Epic does exactly this for a bunch of our own services (Epic account, marketplace catalog, etc.)” - A Helpful Individual

After implementing the same idea using FHttp and some multithreading to wait on a response, the intended goal was achieved. FHttp was the easiest implementation option I felt out of the two, and more strongly suits communicating with a php server as we intend to. Thanks to the Helpful Individual responsible for the push in the right direction. Still curious about why tcp implementation cant seem to handle flushing output buffer without closing, but FHttp works for us.