Re: Socket Question

Hello Mark,

I've seen applications of this type exploit the full duplex capability of
sockets. Full duplex in this context is the concept of data being written
and read to the same socket at the same time. A socket cannot be shared
between two different jobs however, so to make it work, thread programming
is involved. What happens is that the job reading from the socket spawns of
a child thread which takes care of writing to the socket. The scenario is
the following:

- Main thread spawns of child thread and then continously reads data from
socket, assembles message according to data protocol and places message on
an inbound data queue.

- Application server job(s) waiting on data queue receives message, handles
request and places reply on outbound data queue.

- Child thread reads data from outbound data queue, and writes the messages
to socket.

Following this approach your application is practically always (or as close
as it gets) ready to read data arriving on socket as well as get reply
messages from outbound data queue. And you can start as many application
server jobs getting from the inbound data queue as necessary to keep up with
the workload, which can be a very efficient way to make your application
scale (the jobs are already activated, programs initialized and files open
and ready when the request arrives).

Best regards,
Carsten Flensburg

----- Original Message ----- 
From: <mgarton@xxxxxxxxxxxxxxx>
To: <rpg400-l@xxxxxxxxxxxx>
Cc: <rpg400-l@xxxxxxxxxxxx>; <rpg400-l-bounces@xxxxxxxxxxxx>
Sent: Friday, September 01, 2006 8:17 PM
Subject: Re: Socket Question

Michael,

Yes, there is a message header and echo data in the message that
identifies message.  I can interrogate  the message and respond
appropriately.  I guess what I am not sure about is how to handle the
situation where both my process and the vendor try to send at the same
time.    Would I have to check the socket before each send and receive? Do
I do that with the select( ) api?

Thanks.

- Mark