Date: Fri, 15 Nov 1996 11:50:50 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@mt.sri.com (Nate Williams) Cc: terry@lambert.org, jgreco@brasil.moneng.mei.com, jdp@polstra.com, scrappy@ki.net, hackers@freebsd.org Subject: Re: Sockets question... Message-ID: <199611151850.LAA26597@phaeton.artisoft.com> In-Reply-To: <199611151832.LAA12528@rocky.mt.sri.com> from "Nate Williams" at Nov 15, 96 11:32:55 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Non-blocking sockets for reliable stream protocols like TCP/IP are > > a stupid idea. > > > > If I wanted datagrams, I would pick a protocol like UDP. > > You are outta your league now Terry, and into mine. This is what *I* > have been doing for years, and I'd like to think I know a little bit > about it given that it's what I get paid to do. *grin* > > You have *very little* idea what you are talking about here, and in the > midst of the volumnous email said very little in terms of content and > knowledge of what's going on. > > Your best bet at this point in time is to either back off and leave what > little shred of credibility you have, or keep going and lose it all. > > Yes, you *can* use UDP for packets, but it brings with it a host of > other problems too numerous too mention. It's a piece of cake to use > TCP to send 'packetized' data (and for many applications the 'right' > thing to do) IFF you know what you are doing and are aware of the > gotchas, which you apparently don't given your blanket statement. There > are tradeoffs for any solution, and knowing the advantages and tradeoffs > for each is an excercise left for the reader since Terry's advice is > misguided at best, and wrong in the worst case. There is a difference between "packetized data" (formatting of the data stream) and "datagrams". Karl has set up for blocking reads and writes on a reliable stream delivery transport. The writes on the sender are completing successfully. The data isn't getting to the reads on the receiver. Karl wonders how the writes on the server can blatantly lie to him. I suggest he run a network monitor or tcpdump to determine if: o The data is failing to hit the wire (sender bug) o The data is hitting the wire, but is invalid for reassembly (also a sender bug). Tracking this probably requires a third machine, non-FreeBSD, to act as both sender and receiver against FreeBSD. o The data is hitting the wire, it's in a format the receiver should recognize and deal with correctly, but it's not getting to the user buffer (reveiver bug) He should also try AF_UNIX instead of AF_INET (or vice versa) to further localize the problem to the transport or the generic code. He should also try send/recv in place of write/read, since the fd-to-socket interfaceing in FreeBSD may be less than perfect. But then, this is stating the obvious, as you did above when you referred to a formatted data stream as being "packetized". Given the symptoms he described, before it was clear that he was seeing the writes complete successfully on blocking sockets (indicating all data from his user buffer had been placed in allocated network buffers for subsequent transmission), I enumerated all possible circumstances under which he might see the behaviour. Since Karl is trying to address what is obviously (now that he has made the circumstances clear) a bug in FreeBSD, advice about sending datagrams is the last thing he needs. My suggestion about using F_GETFL to look at the socket defaults remains valid. He should do so, since the problem could easily be in bogus defaults supplied by FreeBSD. In terms of "shredded credibility" or "saying very little in terms of content and knowledge of what's going on", I suggest you muck out your own barn before you offer to muck out mine. You could start with acknowledging that what Karl's trying to do should work, and then identifying the circumstances under which it could potentially fail (much as I have done), instead of assuming that both he and I are "idiots who don't know what they are doing". Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611151850.LAA26597>