Suppose I open a socket connection to a remote host, using either an SSLSocket (classic) or having set a particular security level on a TCPSocket (new framework). Suppose also the connection attempt succeeds and I now wish to send a short message to the host using socket.write or .writedata.

It's unclear to me whether each such .write is encrypted and sent ASAP or whether there is an attempt to group them together before sending. All my writes, even those of only a few bytes, seem to go out immediately so I am curious as to how this is organised.

I'm looking into this because at the moment I'm waiting for data to be transmitted (by polling and checking status) before moving on to a read, and I wonder whether I need to bother (I note that the new framework doesn't have a flush method). One place where it might be important is at the moment the connection is to be terminated. It appears that I must send QUIT to the other end (a mail host), otherwise it doesn't delete mails for which I've requested deletion. As I'm doing all this in a thread, I don't want to send the QUIT and then have the thread exit before the message is actually sent to the remote end.

Any comments as to how this works would be appreciated.

@shao s Xojo.Net.TCPSocket is only available on iOS, ...

OK - I'd overlooked that.

Basically I want to know whether, with the old framework and an SSLSocket, I need to use flush() to wait for a write to complete (or do a poll() in a loop and wait for completion status) or whether this is unnecessary.

In the days of RealBasic, flush was often lethal, causing all kinds of mayhem. I can't comment on flush in Xojo.

I've seen on a post in this forum with what purports to be how flush() is implemented. It claimed that flush() is just a loop in which a poll() is done, and a test for BytesLeftToSend, and returns when this is zero. Nothing about stopping data collection. It didn't even appear to test for isConnected.

I've used flush() when isConnected happened to be false; this appears to send the app into a tight loop inside flush() which renders the debugger useless. Since then I've used my own version of flush() which behaves rather better. But I still don't know whether I actually need to do this.