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