*BSD News Article 25775


Return to BSD News archive

Xref: sserve comp.unix.programmer:14190 comp.unix.bsd:13241
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!news.kei.com!world!ora.com!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.programmer,comp.unix.bsd
Subject: Can vread be used with UDP?
Message-ID: <1523@minya.UUCP>
Date: 10 Jan 94 00:36:38 GMT
Followup-To: comp.unix.programmer,comp.unix.bsd
Lines: 33

In a prject I'm working on that uses mostly Suns, we've found that the
speed  of throughput of network servers is exactly proportional to the
number of system calls.  In fact, the primary limit (with the  logfile
suppressed)  is the number of reads and/or writes to a socket that can
be done per second.  That is, the programs are utterly I/O bound,  and
cutting  down  (or  increasing  ;-) the cpu used has little measurable
effect on throughput.

The Suns have these  extra  read()  and  write()  calls,  vread()  and
vwrite(), which handle multiple messages in a single system call. This
is enticing, and looks like the obvious  solution  to  the  throughput
limit.  But there's a big gotcha:  The vread() call, while it can read
multiple messages, seems to have no provision  for  saying  where  the
data came from.  The programs all use recvfrom() now, so they can send
a reply.  There seems to be no (documented) version of recvfrom() that
can deliver more than one message and also indicate the origins of all
the messages.

What I'd really like, of course, is a system call that says  "Give  me
all  of  the messages that you have queued for this socket".  (It'd be
real nice if the system call could malloc the space, but I'm not  that
big  a  dreamer.  ;-) This would, be rather useless unless the program
can send back a reply to each message's sender, which  means  that  it
needs some way of getting the senders' addresses.

If it is documented somewhere, can anyone tell me where?  Or is it all
really  as hopeless as it seems?  Are we stuck with the performance of
two system calls (readfrom() and  sendto())  per  message?   is  there
perhaps something that I've missed in TFM?

-- 
Verbosity leads to unclear, inarticulate things.
   -- Dan Quayle