ronnie@mit-eddie.UUCP (Ronnie Schnell) (02/03/85)
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 with one read. I then have to go through the trouble of seperating these messages. This isn't so bad, but sometimes (often) I will fill up the server's buffer, and stuff will be lost. Am I doing something wrong? Is ipc supposed to do this? If so, is there a way to have the user wait until the server has read the message without implementing my own protocal? #Ron (ronnie@mit-mc.arpa) (..decvax!genrad!mit-eddie!ronnie)
chris@umcp-cs.UUCP (Chris Torek) (02/04/85)
> 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
brad@gcc-milo.ARPA (Brad Parker) (01/27/86)
"Trouble with UUCP on SUN-100; uuxqt won't run anything"
I've sent this request out before, but with no good responces. This time I'll
include everything I've tried - please don't suggest the obvious (such as
checking L.cmds)
I have a sun-100 running V1.3 software. I can uucp files back and forth with
our BSD4.2 (Mt. Xinu) VAX with no problem, but rmail and rnews refuse to
work on the sun. I've tried playing with L.cmds, I've set all the ownerships
and permissions correct (I hope) and still nothing. Here is what I can get on
the console:
in LOGFILE: "root gcc-mil (1/19-22:36-133) brad XQT DENIED (rmail brad)"
To test I send 10 pieces of mail from the VAX to the sun, run uucp manually on
the sun, and kill the uuxqt just as it starts up automagically. After a bit of
clean up, I run uuxqt as root, with -x9 (i.e. cd /usr/lib/uccp; uuxqt -x9)
The console dumps out the contents of L.cmds (which contains rmail) and
the interesting lines are:
<dump of L.cmds>
...
F <some uucp file name>
I <some uucp file name>
C rmail brad
fin - /usr/spool/uucp/D.gcc-milB0pp2, fout - /dev/null, sysout -
gcc-sun, user - brad
cmd - rmail brad
bad command
...
<more of the same, for each X. file>
The interesting part is that in the source reads ("bad command %s", pre)
or similar. I only had time for a quick peek on a friend's system; I couldn't
spend the time to really figure out the possible failure modes to cause this.
(strings confirms this on my system)
Any idea what is causing this? Please don't suggest source code changes,
we're a binary only licence. If this is a code bug, I'll send hate mail
to sun ;-) (they've actually have been very nice!)
Thanks for any help.
brad parker
general computer
harvard!gcc-milo!brad
--
J Bradford Parker
seismo!harvard!gcc-milo!brad
"I want to go up to Detroit
I want to lie in the shade
I want to visit the President
And then I want to get laid" - O.M.D. "Bloc Bloc Bloc"drews@utrc-2at.UUCP (Drew Sullivan) (01/30/86)
In article <453@gcc-milo.ARPA> brad@gcc-bill.UUCP (Brad Parker) writes: >"Trouble with UUCP on SUN-100; uuxqt won't run anything" > From you site name I see that it could be the same problem I ran into. The Makefile for UUCP (4.2) that creates the directories in /usr/spool/uucp/{C.,D.,D.<site>,D.<site>X,TM.,X.,XTMP} doesn't truncate the <site> in D.<site> and D.<site>X names to 7 characters. UUCP and all other uu programs do. I had exactly the same problem and fixed everthing by a simple rename of the two offending directories. Hope this helps. -- Drew Sullivan. utzoo!yetti!utrc-2at!drews -- -- Drew.
wls@astrovax.UUCP (William L. Sebok) (02/02/86)
>>"Trouble with UUCP on SUN-100; uuxqt won't run anything" >From you site name I see that it could be the same problem I ran into. >The Makefile for UUCP (4.2) that creates the directories in >/usr/spool/uucp/{C.,D.,D.<site>,D.<site>X,TM.,X.,XTMP} doesn't truncate >the <site> in D.<site> and D.<site>X names to 7 characters. UUCP and >all other uu programs do. I had exactly the same problem and fixed >everthing by a simple rename of the two offending directories. >Hope this helps. > -- Drew Sullivan. utzoo!yetti!utrc-2at!drews When I was running 4.2 BSD uucp I solved it different way, by removing the stupid 7 character limit on site names. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,vax135}!astrovax!wls