Scenario A : Application is waiting for an event. It gets a FIN from remote, EV_READ event is >generated, application does a read(or recv) and gets 0
Yes - that's right.
Scenario B: Application is sending data. It gets a FIN from remote while the send is being >executed. Will the application get an EPIPE (I think so). Will there also be an EV_READ event >generated for the same FIN for which the application gets an EPIPE
Yes, there will be an EV_READ event generated. (ofcourse provided you didn't close() the socket in the mean time).
However you're not getting an error on write in this very particular case. When you get a FIN from the peer end, the TCP connection is only half closed. The incoming FIN simply means "I've nothing more to send". But you can send it more data. Or you can close() the socket, resulting in a FIN from your side to the peer, and now the TCP connection is considered closed, as you've both sent FIN packets.
At this point it depends on what the peer actually did, whether it called close() or shutdown(). On subsequent write()'s you might get EPIPE or ECONNRESET if the peer application closed its socket and the peer sent a RST, or you might continue sending it data if the peer has been coded to receive more data.
note that you're just describing one particular case. Depending on timing and what's happening on the network or at the peer, there's many, many more cases to consider.
How do I write a remote peer so that the local send returns an ECONNRESET.
This will happen if the peer does a close() while there is still data to be read in the local buffers at the peer. In that case a RST is sent, write/send would error with ECONNRESET, as would a read()/recv().
To generate this case, simply don't read() anything, wait a bit until you're sure some data has arrived, then close() the socket. A later write() on the other end would get ECONNRESET. And another write() after ECONNRESET should get EPIPE.