I've seen EAGAIN as well l as EBADF errors as a "normal" part of operation against TCP sockets. I say "normal" because I've only seen EBADF once and it was because the client side started talking too early. IOW, when select()/poll() tell you socket 13 is ready and recv() tell you to EBADF, then the socket is just not ready to go just yet. Go around again.
The client side grew up against serial ports ( yes, those are still a thing ) , where you don't have this problem. The owner of the client side was more or less in incredulous terror when I broached this subject. Sigh. So I just ignored them. Big sigh. If it failed, there were retries so the only cost was a little delay now and again.
You cannot fragment UDP unless you're prepared to add some method of sequencing as part of the application protocol. Each UDP PDU needs to be fully atomic otherwise.
For cases analogous to SNMP row creation ( in which multiple varbinds[1] determine the outcome ), there is the "as if simultaneous" rule as a heuristic - all PDUs related to creating a row must be cached and only applied when the row state is set. And sometimes you can configure things to send all varbinds in one PDU.
[1] a varbind is a triple of the set/get/next/multi operator, the object id and if applicable a value as encoded by the SNMP Basic Encoding Rules.
So your little serialization protocol? It suffers all the heartache of a full-on transactional database processing system.
These things are this way because communications are like that.
The client side grew up against serial ports ( yes, those are still a thing ) , where you don't have this problem. The owner of the client side was more or less in incredulous terror when I broached this subject. Sigh. So I just ignored them. Big sigh. If it failed, there were retries so the only cost was a little delay now and again.
You cannot fragment UDP unless you're prepared to add some method of sequencing as part of the application protocol. Each UDP PDU needs to be fully atomic otherwise.
For cases analogous to SNMP row creation ( in which multiple varbinds[1] determine the outcome ), there is the "as if simultaneous" rule as a heuristic - all PDUs related to creating a row must be cached and only applied when the row state is set. And sometimes you can configure things to send all varbinds in one PDU.
[1] a varbind is a triple of the set/get/next/multi operator, the object id and if applicable a value as encoded by the SNMP Basic Encoding Rules.
So your little serialization protocol? It suffers all the heartache of a full-on transactional database processing system.
These things are this way because communications are like that.