Re: Socket Question

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

> Then JobB, which connects to the outside vendor, has muliple socket
> connections to the vendor for redundancy and load balancing. I just
> round-robin between the connections to the vendor. If I combined the jobs,
> the new job would need to be able to receive connections from the clients
> and while keeping 4 persistent connections to the vendor.

Ahh, okay... yeah, I think we've talked about this in the past. (I 
remember it now.)

> At this point I am not sure what to do.  I need to get the current process
> working asap.  The redesign is a future project unless that is my only
> choice to get this working.

Here's teh simplest thing I can think of:

a) JobA -- works the way it does now.

b) JobB -- This job will be changed to do nothing but read the data queue
           and write it to a pipe.  (A pipe is like a socket, but it's
           unidirectional, and only communicates with prograsm on the
           same computer.)

    When JobB starts, it does this:

          1) Create the pipe with the pipe() API.
          2) Spawn JobC with the spawn() API, and pass the output
                end of the pipe to JobC, also pass the data queue
                name as a parameter.
          3) Wait for an entry on the data queue.
          4) Write that entry to the pipe.
          5) Go back to step 3 (wait for entry)

c) JobC does the socket communications (the stuff that JobB used to do in
    your old scenario). The only difference is that instead of reading a
    data queue, it now reads from the pipe that was output by JobB.

          1) Do any initialization (as required)

          2) Sit and wait on the select() API. The select() API is capable
               of waiting for data on a set of different descriptors.
               You can wait for data to come in (in a "read set") buffer
               space for writing out (in a "write set") an exceptional
               condition (which doesnt' apply to your scenario, ignore it)
               and a timeout.

               select() will return control to your program as soon as any
               ONE of the preceding events occurs.  So you can tell it

               "wait until the socket from my vendor is has data OR
               until the pipe has data OR until X seconds elapse"

          3) If you get input from the socket, send it to the data
                queue (yes, directly to the data queue... this won't
                cause your program to wait for anything!)

          4) If you get input from the pipe, read it from the pipe and
                write it to the socket.

          5) If you get a timeout, send the keep alive, and check
                 SHTDN / %shtdn().

          6) Go back to top of loop (step 2)

I'm not exactly sure what the vendor sends you, so I guess it's possible 
that some of the data you get from the socket wouldn't need to be written 
to the queue, depending on what it is.  The point is, you spend the bulk 
of your time sitting on select() waiting for any of the possible events. 
So it doesn't matter if you get data from the pipe first, or if you get 
data from the vendor first, either way you can handle it.

Does that make sense?