Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!zehntel!tektronix!decvax!genrad!panda!talcott!harvard!seismo!umcp-cs!chris From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.unix-wizards Subject: Re: Help (ipc question) Message-ID: <2981@umcp-cs.UUCP> Date: Sun, 3-Feb-85 20:38:26 EST Article-I.D.: umcp-cs.2981 Posted: Sun Feb 3 20:38:26 1985 Date-Received: Sat, 9-Feb-85 07:13:04 EST References: <3548@mit-eddie.UUCP> Distribution: net.unix-wizards Organization: U of Maryland, Computer Science Dept., College Park, MD Lines: 22 > I am trying to write a program using 4.2 ipc stuff. What I have > discovered is that when the client does more than one send before > the server does its recv (read), the server will receive both (all > 70) messages at once [...]. I then have to go through the trouble > of sep[a]rating these messages. [...] Am I doing something wrong? > Is ipc supposed to do this? This is what's meant by ``byte stream'' or ``atomic'' protocols. If you have a stream protocol, it presents no record boundaries; if you want any, you have to make them up yourself. If you're using an atomic protocol, then there is something inherent in the protocol that makes each message a single unit. TCP is a stream protocol. UDP is a datagram (atomic) protocol. However, UDP is not reliable (messages can [i.e., will] be dropped or duplicated or reordered). If you're working on a single machine you can use AF_UNIX SOCK_DGRAM sockets to get a 99% reliable datagram protocol. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland