Quote:
Also these sockets are in Non Blocking mode (O_NONBLOCK)
Any reason for not using standard blocking mode?
Quote:
Consider the server tried to write 2464 bytes. But after the repeated 30 attempts it could write only 1080 bytes. Server will raise a EAGAIN at this point. Client try to read 2464 bytes. The read command will return 2464 and hence the read itself is ok. But the data we received is a corrupted one (Partially written data only). So client crashes.
I can't quite follow. If only 1080 has been sent, I don't think that read() returns 2464 bytes...
Quote:
2) Is there any way to identify in client side that we had read a partially written message?.
You need to handle partial read anyway with TCP, since you don't know how your message will be segmented. The usual design pattern goes along those lines:
- a message is composed of a header and payload section,
- the header contains (among other) the payload size,
- the receiver read() first the header (a few bytes), decodes the expected payload length. To get the payload, it re-iterates read() until the wanted size is reached or an error occurs.
Quote:
Please note that we are facing the partial write issue in LINUX(REDHAT 5.4) only. System is working fine in Solaris (In solaris either eh entire data will be written OR NO data witll be written with in 30 tries of write).
Perhaps tune kernel parameters TCP send/recv queue length ?
HTH, Loïc