Re: Socket Programming - Receive

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Hi Lakshmi,

>      The program will not be able to know which structure it is
> receiving.My problem is, how can I identify which structure I am
> receiving in RPGLE.

There's no magical solution to that.  The program that's sending the
structure has to have some way of telling the program that's receiving the
structure which structure it is.

Actually, I suspect that the "bMsgCode" part of the structure was intended
to be used for this purpose.  I can't say for sure, since I'm not sure how
the application works...   But, I would guess that the first 2 bytes
identify the structure, and bytes 3-4 identify the length of data in that
structure.

If that's the case, here's what you want to do:

1) Create a buffer that's the size of your largest data structure.
2) Base all of your data structures on pointers.
3) Set a work-pointer (NOT one of the ones that the structures are based
     on) to the start of the buffer.
4) Receive 4-bytes to fill in the MsgCode and MsgLen parms of the
     structure.  (do byte-swapping if necessary)
5) Based on the MsgLen parameter, receive the rest of the structure.
6) Use select/when or if/elseif on the MsgCode to determine which
     structure you've received, and point that structure's pointer
     at the start of your buffer....
7) Do whatever you needed to do with that structure.

Does that make sense?


> My application in RPGLE sends different messages to a PC and it will not
> wait for the response from a PC.  After sometime, the PC will send the
> response to AS/400, then the RPGLE pgm should interpret the message
> (which structure it is ?) and process accordingly. So, my problem is how
> will the program know the socket is received response from a PC and
> which structure?

I still don't understand.  What is the program doing when it's not waiting
for data from the client?  The program isn't ending, is it?  Is it waiting
for input from a user?  What is it doing?

Normally, you wait for data on a socket in one of two ways...   either by
using one of the recv APIs with a blocking socket, or by using the
select() API to wait until data has arrived.

If you've got something else you need to do, like waiting for input from a
user, then you need to switch back & forth between the user input and the
wait for data.  What I'd do is have the screen input signal an entry on a
data queue -- then do a select() for 0.5 second, check the data queue with
a 0 timeout, then go back to select() for 0.5 second, etc.  When either
the data queue has an entry or the select() API says there's data, you
process the screen or the socket.

Hopefully that makes sense...