NetIPC 3000/XL Programmer's Reference Manual (5958-8600)
Table Of Contents
- 1 NetIPC Fundamentals
- 2 Cross-System NetIPC
- 3 NetIPC Intrinsics
- 4 NetIPC Examples
- A IPC Interpreter (IPCINT)
- B Cause and Diagnostic Codes
- C ErrorMessages
- D Migration From PTOP to NetIPC and RPM
- E C Program Language Considerations

30 Chapter1
NetIPC Fundamentals
Using NetIPC for Interprocess Communication
TCP Access
For TCP access, all data transfers between user processes are in stream
mode. In stream mode, data is transmitted as a stream of bytes with no
end-of-message markers. This means that the amount of data received
in an individual IPCRECV is not necessarily equivalent to the amount of
data sent in an IPCSEND call. In fact, the data received may contain part
of a message or even several messages sent by multiple IPCSEND calls.
You specify the maximum number of bytes you are willing to receive
through a parameter of IPCRECV. When the call completes, that
parameter contains the number of bytes actually received. This will
never be more than the maximum amount you requested, but it may be
less. The data you receive will always be in the correct order (in the
order that the messages were sent), but there is no indication of where
one message ends and the next one starts. It is up to the receiving
process to check and interpret the data it actually receives. An
application which does not need the information in the form of
individual messages can simply process the data on the receiving side.
If an application is concerned about messages, the programmer must
devise a scheme that allows the receiving side to determine what the
messages are. If the messages are of a known length, the receiving
process can execute a loop which calls IPCRECV with a maximum
number of bytes equal to the length of the portion of the message not
yet received.
Since IPCRECV returns to you the actual number of bytes received, you
can continue to execute the loop until all the bytes of the message have
been received. The following Pascal program fragment demonstrates
this idea:
received_len := 0;
while (received_len < msg_length) and (errorcode = 0) do
begin
data_len := msg_length - received_len;
ipcrecv( connection, tempbfr, data_len,,,errorcode );
if errorcode = 0
then strmove(data_len,tempbfr,1,databfr,
received_len+1);
received_len := received_len + data_len;
end;
In the above example, the Pascal function strmove takes each piece of
the message received in tempbfr and concatenates it to the portion of
the message already in databfr. Upon exiting the loop, the entire
message has been stored in databfr.
If the length of the messages are not known, the sending side could
send the length of the message as the first part of each message. In that
case, the receiving side must execute two IPCRECV loops for each
message: first to receive the length and then to receive the data. An
example of this technique is shown at the end of this section.