Stephens, Allan wrote: > Hi Florian: > > This is a very interesting result. I think you are correct in observing > that there is no reason for TIPC not to return as much data as it can > during a stream-based receive operation, and your suggested modification > looks good to me. However, I'd like to see if people agree with the > reasoning I've used to arrive at such as conclusion ... > > I believe that the code exists in its current form is because I > mis-interpreted the IEEE Std 1003.1 description ...
Yes the standard is not very clear... > > Later on, the standard says: "If the MSG_WAITALL flag is not set, data > shall be returned only up to the end of the first message." I had > originally thought this statement applied to all socket types, which is > why TIPC's receive code currently bails out once it reaches the end of > the first [TIPC] message in the receive queue. However, upon reading > some of the surrounding text, I now think that the term "message" refers > to the atomic data units sent by SOCK_DGRAM, SOCK_RDM, and > SOCK_SEQPACKET, meaning the statement does NOT apply to SOCK_STREAM; > consequently, we can/should ignore the TIPC message boundaries in a > SOCK_STREAM receive even when MSG_WAITALL is not specified, just as > Florian suggests. I agree. The simple example that I think of is if I want to send a series of variable length messages over a stream socket Len1 Payload1 Len2 Payload2 ... If my lengths are always 4 bytes, I should be able to do: recv(fd, &len1, sizeof(int32_t), 0); p1 = malloc(len1) recv(fd, p1, len1, 0); recv(fd, &len2, sizeof(int32_t), 0); p1 = malloc(len2) recv(fd, p2, len2, 0); I've left out the error handling that has to deal with the recv call being interrupted due to a signal but I don't think one should have to specify MSG_WAITALL here. > > However, there are still a couple of questions we need to answer: > > 1) If we use Florian's modification, TIPC will still only return data > from the first message in the receive queue when both MSG_PEEK and > MSG_WAITALL are specified, rather than taking as much data as it can. > Is this what we want? No. It's a stream socket and the user asked to fill the buffer (MSG_WAITALL). I don't think this is optional. Most likely calls like this will be to peek at a 4 byte message length but I think TIPC has to handle the general case. > Personally, I'm OK with this. I don't think it's > worthwhile to further complicate the recv_stream() routine by requiring > it to copy data from a message that isn't the first one in the receive > queue, and I doubt people will specify both of these flags in the same > receive anyway. I've heard that before! ;-) > Also, bailing out after the first message when MSG_PEEK > is specified appears to be compatible with the wording of the standard, > so I don't think people could complain we weren't doing the right thing. Didn't we agree that it's a poorly worded standard? > 2) We need to define what MSG_WAITALL means for a non-stream socket. > The final statement in the standard raises the possibility that you > could use MSG_WAITALL to receive multiple atomic data units in a single > receive (although the final one might be truncated), however it doesn't > actually require this (i.e. it only says what should happen if the flag > is not set, not what should happen if it is set). Personally, I think > using MSG_WAITALL this way conflicts with the atomic nature of > non-stream message sends, and (again) I doubt many users will want to do > this sort of thing anyway. TIPC's receive code currently ignores the > MSG_WAITALL flag for non-stream sockets, and as long as we point this > out in our documentation I don't think we will get too many complaints. Having message oriented sockets ignore MSG_WAITALL sounds good to me ...but... One thing that might make sense is to return an error and set errno to EOPNOTSUPP? Comments? // Randy ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
