ipc, tli or sockets?

[klaus u schallhorn]

I guess it's time, even at 10pm, to get my mailbox in order. Some time ago
I asked the net for some advice about inter process comms via ethernet.

I received a number of replies, one suggesting RPC, one suggesting TLI,
and the balance being clearly in favour of sockets [often giving reasons
for not using anything else].

On my very first attempt using sockets I got utterly stuck. Not with
sockets as such, mind you, but driving a serial port faxmodem.  I've just
been able to finalise a function on which I was coding for now [about]
four weeks. This is one of the reasons why this reply is so terribly late
[and I do apologise].

Browsing through the Sun docs after having received the majority of
replies, I looked into RPC and TLI [TLI being officially favoured by Sun]
and had to agree with those prefering sockets.

Coming to grips with sockets gave me another reason not to even consider
TLI. In a number of places the Sun docs mention patchy groundwork in TLI
[page 259, net prog man, chap 10 and others]:

| "Sockets under TLI Emulation: write() should fail with errno set to
| ENOTCONN if it is used on an unconnected socket, however, under TLI
| Emulation, it will instead return success..."

What a novel way to create fault tolerant behaviour. I shall adapt this
strategy ;-)

I have already modified [and tested/used] several pgms that eventually
become part of the new dbms setup. So far I found sockets to work as
advertised, with no one really noticing they're calling a remote machine.
On one program [an interface to several shell scripts] I actually went
[what's the inverse of over the top?] and used the stdio library on both
ends [using fdopen() after having a socket] !!!

Having only recently installed my first ethernet I must say I found the
socket based approach a solid success. 

Before I include some of the responses let me express my thanks to all
that found the time to help me make a correct decision.

Klaus

One final word: given the fact that we currently use sun{3,4}'s only I'm
not too concerned with byte ordering. I know the processor types will not
change in the near future.

=====================================================================

X-From: Guy Harris <auspex!guy>

>According to sun, sockets are a no-no as of 4.1 [they still work and are
>used by sun], to be superceded by TLI in the near future. All new
>applications should be done using TLI.

Well, that's what some folks at Sun may have said in one of the manuals,
but it's not exactly the case (as other folks from Sun, e.g. Bill Melohn,
have noted).

TLI, in SunOS 4.1, is actually partially based on sockets; basically,
there's a TLI-compatible "/dev/tcp" device into which the standard
sockets-based TCP implementation can feed input and from which it can
accept output.  The rest of the networking stuff in 4.1 is sockets-based.

AT&T is somewhat pushing TLI as the "correct" interface to use in System
V, which is why that recommendation showed up in the SunOS documentation.
However, System V Release 4 includes a sockets interface that's
considerably closer to the BSD one than the one that various S5R3-based
systems have (Sun did a lot of it - it's built atop streams+TLI - and did
a paper on it in the Winder 1990 USENIX proceedigs), and it's intended to
be as compatible with 4.3BSD/SunOS 4.x sockets as possible.

>Anybody cares to voice an opinion? I'd prefer sockets, but if they're to
>go "real soon now", I might delve into tli.

I don't see sockets disappearing any time in the near future; as
indicated, S5R4 has 'em as well as TLI.

==========

X-From: Rich Stevens <rstevens at noao.edu>

I'd recommend sockets, just because there's more documentation out there
on how to use them, and more experience on the net with sockets.  Given
the amount of networking code that exists today that uses sockets, they
won't disappear, despite what Sun (actually AT&T) says.

==========

X-From: jkay <(Jonathan Kay)cs!jkay at ucsd.edu>

No matter what Sun may say, I do not think that sockets will disappear
from their OS any time in the next five years at least.  They do, after
all, want to keep on selling more Suns...WAY too many programs use socket
libraries.  Now, you may be able to squeeze more performance out of TLI,
but I rather doubt it.  As one who has programmed using the TLI, let me
note that it was not a pleasant experience.  As is common with software
from AT&T, it hardcodes things that need generalizing, generalizes things
that are just fine.  TLI is exceedingly unpleasant to use.  

P.S.: In TLI, just getting a file descriptor to which you can read/write
	takes extra work!

==========

X-From: Chuck Kollars <ckollars at east.sun.com>

Many people think the statement in the manual is too strong.  In fact it
will _probably_ be softened or maybe even removed from the next version of
the manual.  

If you use the TLI interface, you're more likely to be able to easily
migrate your application to using OSI protocols in the future.  (This
isn't to promise that such a migration will be painless or completely
successful, just that it's more likely to work for a TLI-based application
than it is for a sockets-based application.)  

In SunOS 4 sockets are the "native" calls (the ones in the kernel), and
the TLI interface is provided by a compatibility library that sits on top
of it.  In SunOS 5 the situation will be reversed.  The TLI interface will
be the "native" one, and the socket interface will be provided by a
compatibility library. 

They're not "going away real soon now".  Some sort of socket compatibility
feature will be around for a loooonnng time.  Don't worry about your
application being stranded.