Blocking send with result with new IP drivers?

[zimri-leisher]

Hello,
I see that the way that ByteStreamDrivers work has changed in 4.0.0a1. It would be nice if there were a clear explanation of the difference somewhere. I checked the release notes and the PR description and could not find an explanation of the change or the rationale.

It seems that now the send port does not directly return a send status, instead we have to receive that send status on a separate port.
Is there still a way to make a blocking send, and get the status of that send in the same method?

[thomas-bc]

Oversight on our end to have missed that on the release notes, I'll add something.

The rationale for this was to make the interface agnostic to whether the driver is able to provide synchronous writes, or if it replies with a status asynchronously. Components interfacing with the interface have to handle the return of the status (as well as ownership of the sent buffer). This makes components in core F´ that interface with a ByteStreamDriver more reusable, as they won't need changing should the driver be asynchronous.

The other change is to align better with the "buffer return" pattern that we're trying to adhere to in core F´ components, where buffers that come out of a component (that may have been allocated) are expected to return to it, so the component itself can handle potential memory allocations/deallocations, and the topology doesn't have memory-allocation-roundabouts where you need to know where to enter and exit, like we had before (see these changes for reference)

Let me know if you have feedback

[zimri-leisher]

The rationale makes sense. However, it's now quite difficult to synchronously await the result of a send. We would have to perform the async send, and set some internal state to track that it's awaiting a response back. Then, when we get the response, we would also have to check that it was for the correct message. I don't even think it's possible to distinguish between two sends of the same data to different IPs with this setup, so we wouldn't know which one failed.

Looking at how different networking solutions handle sync/async network actions, they are usually different functions. I would suggest having a separate port on all network drivers that is a "sync" send.

[LeStarch]

In the sync case, the response would arrive at the caller before the send function returns. That should allow you to distinguish which message was sent.

[zimri-leisher]

Good point, yes it would allow us to distinguish, but it would be kinda ugly because we'd have to track some internal state about which packet we were expecting back. It seems like a hack.

[zimri-leisher]

Thoughts on this solution:

Looking at how different networking solutions handle sync/async network actions, they are usually different functions. I would suggest having a separate port on all network drivers that is a "sync" send.

@thomas-bc @LeStarch

We could upstream this