Hi Randy: Thanks for your comments. You're right that we have to be careful about saying "no one will want to do this", since our track record here seems to be somewhat spotty!
I can agree that it is probably desirable in the long run to have TIPC handle simultaneous use of MSG_PEEK and MSG_WAITALL as you describe, but I suspect it will be a while before anyone gets around to implementing the change. There just seem to be too many other more significant issues to address first. I also considered putting in the EOPNOTSUPP check you suggest when MSG_WAITALL is used with non-stream data, but I'm not sure whether the cost of introducing yet another error check in the data path is worth it -- especially when the impact of not doing the check is low (i.e. it's not like we'll get a kernel panic) and the likelihood of the check being triggered is also low. On the other hand, maybe our philosophy should be "use the native API when you want to maximize performance and are willing to accept fewer error checks, otherwise use the slower and safer socket API", in which case the check you suggest would be appropriate. What do other folks think? Regards, Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Randy Macleod Sent: Tuesday, June 26, 2007 9:48 AM To: Stephens, Allan Cc: [email protected] Subject: Re: [tipc-discussion] TIPC slower than TCP - really? 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 ------------------------------------------------------------------------- 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
