RE: TCP/IP Server concepts (RPGLE)

David,

You can do this.  Easyily in C, a little bit (but not much I suspect) 
harder in RPG.

First, create a subsystem for the monitor & client jobs to run it.  It 
should be maxjobs(*nomax) on both the subsystem and the job queue.

next, create a "Socket Monitor" program.  More details below. This 
program does not actualy handle the client, it only listens for the 
connect requests from the client.  Set this up as an autostart job in 
the above subsystem.

The first thing this job/program does is create/clear a data queue. 
 Lets call it TAKEDQ.  Then submit 2 "Client Processor" jobs to the 
jobq.  The exact number can vary based on the load.  I use 2.  One 
would also work.  More than 10 or so is probably over kill.   These 
are kind of a "prestart job".

Now, the Socket Monitor should do its normal stuff to initialize 
itself and sockets.

The mainline should then hang on a listen().

When it returns from the listen (with no error), create a new socket 
and pass it to accept().

Now submit a new monitor.  We are about to take one of the idle 
montors.  This sbmjob creates a new one.

Now, do a QRCVDTAQ on the TakeDQ data que.  When the client jobs 
starts, they send a data structure with their job info  in it 
(specificly a JobID) to this data que.  With this job id, now do a 
givedescriptor() passing the socket handle and JobID retrieved from 
the data queue.

The monitor now loops back up and does a listen() again.

In the Client Processor, the first thing it does is retrieve its JobID 
(via QUSRJOBI API), and sends it to the Socket Monitor via the Data 
Queue.

Now, it issues a takedescriptor(NULL);  This will hang until the 
monitor process issues a givedescriptor against it's JOBID.

When the takedescriptior returns (with no errors), the client 
processor now "owns" the socket and can do as little or as much as it 
wants without worrying about other clients.

Clear as mud by now? <g>

It really is not as hard to do as the above implies.  And it works 
VERY well on systems down to V3R1.  I use this technique in a 
commercial product (you guessed it, Fax Server/401) and have had no 
problems.

If you are on a release that support threads, V4R1 or V4R2 I think, 
this is also an ideal use of multi threading...and is how I do things 
in my WinNT socket servers. With threads, you can skip all the stuff 
about data queues etc and replace it with attach() and detach() calls. 
 BTW, I do not know how well RPG handles a multithreaded 
enviornment..this MIGHT cause you SEVERE problems.

Regards,
Bob Crothers
Cornerstone Communications, LLC
www.faxserver401.com

another day done
all targets met
all systems fully operational
all customers satisfied
all staff keen and motivated
all pigs fed and ready to fly...




-----Original Message-----
From:   David Gibbs [SMTP:David.Gibbs@IL.US.MKS.com]
Sent:   Tuesday, April 13, 1999 11:27 AM
To:     'Midrange Mailing List'
Cc:     Brad Sommerfeld
Subject:        TCP/IP Server concepts (RPGLE)

Ok, here's a question for all you "Bare Metal" Programmers out 
there...

I've got a simple TCP/IP server written in V3R2 RPGLE and it works ... 
but I
need to make the process more robust.

I need my server program to be able to handle multiple clients at the 
same
time... but in a "Stateful" manner (i.e., the server has to do a whole 
bunch
of work for the client and keep track of what is going on).  Kinda 
like
evoking an ICF comms program and carrying on a conversation (send, 
receive,
send receive, etc).

>From my research, I've determined that if the server were written in 
C... on
Unix... I would use the "fork()" operation to detach from the current
process into a child process and the socket would handed off to the 
child.
The server program would then allocate another socket and go back into 
a
"listen()" mode.

Is this basic logic possible to do in V3R2 RPGLE?  Am I biting off 
more than
I can chew?

Thanks!

david


--

David Gibbs
Sr. Software Engineer
Mortice Kern Systems US, Inc.
2500 S. Highland Ave., Suite 200
Lombard, IL  60148

phone: (630) 495-2108 x5004
http://www.mks.com <http://www.mks.com/>
mailto:dgibbs@mks.com <mailto:dgibbs@mks.com>


Opinions expressed are strictly my own and do
not necessarily reflect those of my employer.


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to 
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: 
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---