Date: Sun, 30 Sep 2001 21:28:26 -0500 From: Alfred Perlstein <bright@mu.org> To: arch@freebsd.org Cc: iedowse@freebsd.org, wpaul@freebsd.org Subject: RPC over unix domain socket issue. Message-ID: <20010930212826.O59854@elvis.mu.org>
next in thread | raw e-mail | index | archive | help
I recently did some work for my employer using FreeBSD+Sun-RPC over a unix domain socket. One of the problems I had was that large responses would fail, the reason being that sendmsg would return EMSGSIZE for transfers that were too big. Basically the workaround for me was to chunk up the responces to smaller PIPEBUF writes. I know PIPEBUF is incorrect, but using getsockopt to fetch SNDBUF returns a value that when used will also EMSGSIZE me. So first off, FreeBSD broken for large RPC responses over unix domain sockets, second, what's the correct thing to do here to avoid the EMSGSIZE without using a bogus very small send size? Is there some interface I need to use to get the max msg size to use? One other thing I noticed was that the client code simply discards any ceredentials it reads, and the server sends them anyway. I was able to change the server to client communication to use simple read/write syscalls and it worked just dandy. Any reason for not doing this? I understand why we might want to check the credentials of the server, but currently the RPC over unix domain sockets doesn't do this, a workaround (if you don't trust the server) is to have your client rpc tell the server to generate a callback to you where you can then check the credentials. So basically we can fix it by either figuring out the max message size and chunking our responces, or we can just switch to using read/write for server->client responces, although that doesn't fix the possiblity of a large request, however that's unlikely unless you're passing large strings around... These bugs are both in the old RPC and the newer tiprc. Any suggestions? I suspect that we may have to fix most of the transport layers to avoid EMSGSIZE not just the unix domain socket transport, but I wanted to get suggestions from the experts. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010930212826.O59854>