Date: Sat, 22 Feb 1997 11:19:14 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: hackers@freebsd.org Subject: Re: Alternatives to SYSV IPC? Message-ID: <199702221819.LAA04898@phaeton.artisoft.com> In-Reply-To: <Mutt.19970222122927.j@uriah.heep.sax.de> from "J Wunsch" at Feb 22, 97 12:29:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > ..., but what about messages? Sockets could be used, but they just > > provide an arbitrary stream of bytes, not discrete messages. FIFOs > > have the same problem, and pollute the filename space (I have the > > same problem with using mmap() for shared memory). > > What else than `an arbitrary stream of bytes' is a message? A *framed* stream of bytes. A reliable datagram of a given size. > Define > your message to be a structure, with a length and type field at the > beginning, and type-dependant data following. This frames the byte stream on send. Because of the recv() does not block for the full requested amount, it will *not* frame the receive. The length field would not be necessary if the framing were enforced by the transport: a receive into a buffer larger than the maximum allowable message type that could be framed for any given transmitter state would be sufficient. You do a recv into the buffer, then you dispatch based on a field dereference from the newly acquired data (probably a type field), and dispatch the data for processing from a big switch statement. No additional recv's necessary. Twiddling around SO_RCVLOWAT and SO_RCVTIMEO would only work if all your datagrams were identically sized. 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?199702221819.LAA04898>