Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request From: davis@scrsu1.sdr.slb.com (Paul Davis) Newsgroups: comp.sys.sun Subject: help needed with INET sockets Keywords: Networks Message-ID: <8904132245.AA22070@rice.edu> Date: 27 Apr 89 10:57:05 GMT Sender: usenet@rice.edu Organization: Sun-Spots Lines: 38 Approved: Sun-Spots@rice.edu Original-Date: Thu, 13 Apr 89 17:02 EST X-Sun-Spots-Digest: Volume 7, Issue 259, message 13 of 13 Hi, I'm trying to write a new version of comsat(8) (rcomsat) for use in a networked environment. The (trivial) mailbox summariser is complete, and I've been trying to figure out how to do the one key thing that comsat(8) does not: listen on the datagram port associated with biff(1) (normally 512) ON A REMOTE HOST. Now it seemed to me that this is what Internet domain sockets were all about: I should be able to open a socket to the remote host etc. etc. etc. However, all the examples I can find assume that the connection to the remote host is done by the client process, whilst the `server' runs on its own host. What we have here is rather the other way around: - /bin/mail writes to the biff datagram port on its own host (client) - rcomsat will listen on the biff datagram port on a remote host (server) Moreover, all the documentation I've seen specifies that the listen() and connect() calls work only on a socket of type SOCK_STREAM. So - 1) Has anyone done this already ? 2) If not, then can anyone indicate the rough outline of what I need to do to get a `server' to listen on a datagram port of a remote machine ? 3) does anyone think that this is a ridiculous idea ? your wisdom and comments are appreciated (and necessary :-) Paul Paul Davis at Schlumberger Cambridge Research [[ You can only bind to a port that is on your local machine. It doesn't matter whether you are client or server. Every connection that a program deals with has a local end and a remote end. The local end MUST be the local host. --wnl ]]