shenjian writes: > James Carlson \xE5\x86\x99\xE9\x81\x93: > >> I wrote one test case: client and server, to send and receive urgent > >> data. When there is urgent data comes, server should get the SIGURG > >> signal and call the signal process function to receive the urgent data, > >> meanwhile there should be nothing returned from recv function which is > >> used for receiving normal data. But in Nevada, it return -1. > >> > > > > Did it perhaps return with errno == EINTR? > > > > > Yes, it return with errno == EINTR. But I think it should not return.
How did you set the signal handler? If you establish the signal handler with sigaction(2) and you supply the SA_RESTART flag, it should generally not return with EINTR. If you establish it without that flag, then it _should_. I think signal(3C) behaves like sigaction with no flags. > >> Another unusual appearance appears in loop-back, that is client and > >> server in the same machine and use 127.0.0.1. The result is not correct. > >> > > > > What result? Need details here. > > > > > In client: send(sockfd, "56", 2, MSG_OOB). > In server, it should only take 6 as urgent, and take 5 as normal data. > But in loopback, server regards both 5 and 6 as urgent data. Are you using OOBINLINE? It sounds like you're not. I agree that this is possibly anomalous behavior, and possibly even a bug, but I'm not sure how much we should try to support this odd case. Most (all?) applications that have to deal with OOB do so by sending a _single_ OOB byte at a time, and by using OOBINLINE, and _assume_ that TCP will coalesce urgent marks by advancing the mark in the stream. Does this odd behavior happen when using non-loopback traffic, or just loopback? TCP has only a single "urgent" mark for a given stream, so it's not possible to have that mark pointing at two unreceived bytes at one time. The usual usage is to start reading and discarding data until SIOCATMARK returns true on SIGURG -- it's a "flush" signal. > > Please provide more details about what you're actually doing (with > > source if possible), the precise results you see, and consider using > > one of the current development mailing lists. > > > > > Attached are the source code of client and server. you can make sure if > you like. Anyway, I am not very familiar with Nevada. So I would like to > have your suggestions if I made any mistake. Thanks very much! I'd suggest running it on a variety of systems before worrying about it as a bug ... I doubt it works the same on all. For what it's worth, I tried running it on AIX 5.2 using loopback, and I saw: Send 2 bytes of OOB data:56 SIGURG received recv 1 OOB byte: 6 error occured:: Interrupted system call So, that system does seem to handle the multi-byte byte OOB correctly, and it returns EINTR (which you're not expecting). -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________ networking-discuss mailing list [email protected]
