Is there a way to know when a transmission completes sending?

[JetForMe]

I can fire off a write to the TCP connection, but afaict there’s no way to know when it completes, is that right?

[mathieucarbou]

I can fire off a write to the TCP connection, but afaict there’s no way to know when it completes, is that right?

which use case ? you are using AsyncTCP as a client ?

If yes, when you do client->write(); then it writes on the wire and returns the number of bytes written.

[JetForMe]

Okay I finally got past another problem that was preventing me from working on this. Here’s what I'm seeing happen: I send a lot of ~2K buffers via write(). For the most part, this keeps going. But when it starts to break down is when write() can't send the full buffer in the call, and returns a lower count of sent bytes. At this point I try a loop like you have above, but it just spins tightly in that loop trying to send, and nothing goes out. Eventually more gets sent. This kinda defeats the purpose of an asynchronous API, and I'd really like to know when it finishes sending whatever caused it to back up. I'm not sending a ton of data, 64 kB/second (at least, I don't think that's a ton).

[me-no-dev]

the best way to handle writes is to couple then with onAck that tell you that what you sent was received by the other end and that you can send more data. If write returns less, that means that you have filled the TCP window of the client and you need to wayt for some data to be acked by the other end

[mathieucarbou]

I think you can use the onAck callback - I am currently writing an example because we do not have one in the project for your use case

[mathieucarbou]

@JetForMe : please have a look at this new example - I added an AsyncSend example showing how to use the ack callback and write for asynchronous send.

  This example demonstrates how to send data to a remote server asynchronously.
   Run on the remote computer: nc -l -p 1234

   You should see in the logs:

Connected!
Will send 5760 bytes...
Acked 1436 bytes in 19 ms
Will send 1436 bytes...
Acked 1436 bytes in 2 ms
Will send 996 bytes...
Waiting for acks...
Acked 1436 bytes in 1 ms
Acked 1436 bytes in 5 ms
Acked 1452 bytes in 17 ms
Acked 996 bytes in 28 ms
Buffer received - next send in 2 sec
Will send 5760 bytes...
Acked 1436 bytes in 14 ms
Will send 1436 bytes...
Acked 1436 bytes in 2 ms
Acked 1436 bytes in 0 ms
Acked 1452 bytes in 1 ms
Will send 996 bytes...
Waiting for acks...
Acked 1436 bytes in 3 ms
Acked 996 bytes in 18 ms
Buffer received - next send in 2 sec

   And in the remote terminal 3072 characters sent [.........  ...........] and so on.

First I am filling the PCB space until I can, or until the buffer is sent.
Once buffer is sent in full I wait for all the acks before sending new one after 2 sec.
You are not forced to wait for acks - that's just a way to demo how to get feedback as you wanted and I am pausing otherwise too many logs ;-)

[JetForMe]

Thanks for that. I think that's a good solution. For now I put in a 100 ms delay if write() comes back with fewer than the requested bytes, and that seems to be working well. If that 100 ms ends up being precious time I need on that core, I'll move to the ack mechanism.