Re: Local Sockets vs. Data Queues

[Scott Klement <klemscot@xxxxxxxxxxxx>]

When you say "local sockets" do you mean Unix-domain sockets?  i.e.
AF_UNIX or those created with the socketpair() API?   Or do you mean
TCP/IP sockets where you connect to 127.0.0.1?

The nice thing about using TCP/IP sockets is that you can have the same
server program which can be used with both local clients and remote
clients.   And the remote clients can be on your LAN or on the Internet
or dialup, etc.  And every modern OS supports TCP/IP sockets.

Here are some of the functional differences between sockets & data queues
that you might use when designing an app:

1)  Data queues are easier to work with.

2)  Data queues allow you to continue adding entries to the queue, even
       if the server program isn't running.   The entries just build up
       in the queue (like a file) until the server comes online and
       starts reading them.   Depending on your application, this might
       be good -- or bad...

3)  Sockets give you an immediate indication when the server isn't there
      you can't queue up data to be received by the server later.  If
      it's not there, you can't queue data up to wait for it.   This is
      a good thing if you've got an interactive application where you
      want an immediate response.   It might not be good, however, if
      you're just kicking something off that is to be processed later,
      or in batch.

4)  If you use TCP sockets (SOCK_STREAM) then you don't have a "record
     size" that you need to worry about.  Like if you're transfering
     a stream file, it's somewhat easier to do with sockets.  You
     don't have to convert the stream into records, then break it
     back out again on the other end.  (not that that's very hard)

5)  Sockets are somewhat nicer for bi-directional communications.
    to achieve the same thing with data queues, you could use a
    keyed data queue, and have a key that indicates the server or
    client that is to receive it.   You don't need to do all of
    this with sockets, though, it addresses and delivers the
    data for you.

6)  Data queues are nicer for multiplexing screen IO with communications,
     or ICF IO with communications...   Sockets are nicer when
     multiplexing multiple simultaneous sockets...

Shrug...  thats all that pops into my head.  There really isn't a
right or wrong solution, as long as it fulfills the business reqs.


On Wed, 17 Apr 2002, Tom Daly wrote:

> Hi all,
>
> Just wondering if anyone has any experience with local sockets.  Do they
> offer something that a dtaq doesn't?  Why would I want to use one instead of
> the other?
>
> Any insights or experiences appreciated.
>
>
> TIA,
>
> Tom