Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!husc6!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: is this wise?
Message-ID: <30750@bu-cs.BU.EDU>
Date: 6 May 89 15:25:12 GMT
References: <378@chessene.UUCP> <53756@uunet.UU.NET> <16437@rpp386.Dallas.TX.US> <53862@uunet.UU.NET>
Organization: Boston U. Comp. Sci.
Lines: 96
In-reply-to: rick@uunet.UU.NET's message of 5 May 89 22:25:12 GMT


From: rick@uunet.UU.NET (Rick Adams)
>tcp_open() isn't a system call. It's a user level abstraction that
>does what you want (i.e. a simpler interface to getting a tcp
>socket).

Appended below is some example code I put together for a systems
programming class I taught at BU a while back, it might not be perfect
but I think it shows the concept Rick describes is pretty easy to
implement.

This is for the server side but could easily be adapted for the client
side, in fact client is much simpler.

The fundamental question, whether or not the tcp network name space
should be merged with the unix file name space is much more
complicated.

I guess for starters I'd hate to see someone cook up a solution that
only works for (most likely some simple subset of) TCP without
considering network protocols in general (eg. UUCP, OSI, etc.) and
distributed processing in general (the line between two processes
cooperating across a network and multiple processes cooperating on one
machine, particularly in a multiprocessor environment, can be very
subtle.)

It also is not very hard to write a version of open() which snoops the
pathname and decides whether or not to simulate TCP in the file name
space or to just pass the name to the real open() as a library
routine. I'd like to see that experiment done and a bunch of real
applications made to use it before deciding the whole thing can be
thrown into the file system. I'll bet lots of issues start to get in
the way and it turns out to be a lot harder than it seems, tho
probably not impossible (ITS and TWENEX had file name space TCP
implementations, I remember TWENEX's implementation required some
bizarre things to be put into the name to handle various options, it
was discouraging to say the least.)

	-Barry Shein, Software Tool & Die

----------

/*
 *	Establish() me as a network server, return socket to
 *	accept() connections on or error. Args are same as for
 *	getservbyname() [see UNIX/4.2 PM (3)]
 *	Actually, if we were willing to be less generic some of this
 *	could be simplified.
 */
SOCKET
establish(service,protocol) char *service, *protocol;
{
	SOCKET s ;
	struct sockaddr_in sa ;
	struct hostent *hp ;
	struct protoent *pp ;
	struct servent *sp ;

	/* clear out the socket structure */
	bzero(&sa,sizeof sa) ;
	/* find out our host's info into hp */
	hp = gethostbyname(myname) ;
	if(hp == NULL) goto bad ;	/* oops, we don't exist? */
	/* get the tcp protocol info */
	if((pp = getprotobyname(protocol)) == NULL) goto bad ;

	/*
	 *	Note: we'll use this later, for now let UNIX
	 *	assign us a socket number to listen on
	 *
	if((sp = getservbyname(service,protocol)) == NULL) goto bad ;
	 */
	/* set up the address family we will use */
	sa.sin_family = hp->h_addrtype ;
	/* zero means let UNIX choose a port -- temporary */
	sa.sin_port = 0 ;
	/**/

	/*
	 *	Get a socket to set up for them
	 */
	if((s = socket(hp->h_addrtype,SOCK_STREAM,pp->p_proto)) == ERRSOCKET)
		goto bad ;
	/* actually bind it to an address for everyone to see */
	if(bind(s,&sa,sizeof sa,0) < 0) goto bad ;
	return(s) ;
bad :
	return(ERRSOCKET) ;
}

-- 

	-Barry Shein, Software Tool & Die

There's nothing more terrifying to hardware vendors than
satisfied customers.