RE: Local Sockets vs. Data Queues

Hi Scott

A couple of clarifiers in-line

>Did I say it was less work?  What I was trying to say is that when you use
>TCP/IP sockets, it's the exact same amount of work to put the
>client/servers on another machine, even if they're connected via dialup
>or Internet.

I think I translated "easier" into less work. My semantic error ;)

> > I've used data queues many times to control server processes but if there's
> > a better way I'm all ears.
>
>Hmmm...  What do you mean by "better"?   It seems to me that what's
>"better" and what's "worse" depends entirely on the needs of the project.

You know, improve how things are done. How can I make a judgement based on
the needs of the project if I don't understand a technique ?

> >> BTW Scott, the two way communication - I find it easier to just have a
> > queue for each process. Part of the information a job sends to the server
> > on it's queue is the name of the queue to respond on.
>
>Seems to me that you have the same problem, there.   Each client needs
>to send it's "address" (job number, client number, queue name, whatever it
>is, some unique ID) in each message that it sends to the server.  Which

Well, so far the AS/400 has always helped with this by providing me with
job number. Add an application prefix and you're done (Yeah I know its not
quite that simple but you get my drift)

>I've used that scenario before...  But I've found that a keyed data queue
>works better because you only have one object on disk, and don't have to
>worry about programs that crash and don't clean up after themselves.

I try and design so all this stuff as transient and since I can never
account for what operators do I clean up at both the front and back of the
process. I agree re disk - lots of temp objects can be a pain so I might
have another think about how I do this.

>But, for inter-system communications, they could interfere with each other by
>sending messages to each other's queues, or "spoofing" the other's unique
>ID -- and there's really nothing you can do about that with data queues.

Like I said to Tom the "inter-system" part was the part I missed.

>But, data queues are much easier to learn and implement... so, like I
>said, pros and cons...

Thanks for taking the time to respond I appreciate it !

Regards
Evan Harris