> > > Does the IPC unit written for linux by Michael Van Canneyt now

support other

Thank you for your comments gentlemen.

My findings thus far are that the simpleipc is the only "portable" and available unit for inter-process communication I see in the 2.0.4 distribution.

The ipc unit itself isn't even "available" for Win32 platform in my copy of 2.0.4.

Looking at the code for simpleipc, thus far, I get the impression that descendant classes need to written in a special way if I want to extend the class further. I'm referring to the code like this:

---SNIPPET--BEGIN

constructor TIPCServerComm.Create(AOwner: TSimpleIPCServer);
begin
  FOwner:=AOWner;
end;

---SNIPPET--END

There is procedure defined in TSimpleIPCClient named:
    Procedure SendStringMessage(Msg : String);
And a mate function defined in TSimpleIPCServer named
    function GetStringMessage: String;

If I could add a new pair of functions to the fcl simpleipc unit such as : SendAnsiString and GetAnsiString I could probably accomplish what I am trying to do without needing to make a descendant.

I would like to be able to arbitrarily send messages as small as one byte to a megabyte at a time.

One example is with my Jegas Information Server, a CGI program.

The CGI program (the cgi thin client.. rather tiny in win32- 50k bytes) gathers all the CGI environment information and saves it to a binary file with a unique id for a file name and waits for a response output file - Ultimately a web page or page redirect or something.

The Jegas Information Server has idle - threads to handle responding to the web requests that come in. When it sees a new file come in to be processed, it loads the data - prepares the thread - and away it goes. Effectively creating the output that the CGI thin client is waiting for.

I understand that if I made my own "simpleipc" class - (which has platform specific code in the *.inc files) that I can make my own message types etc.

I also know that if I could just send ansistrings back and forth, I can do ansistring magic (I love FreePascal ansistrings... have I said that?) where I may stack a bunch of data in one long byte sequence that the receiver can decipher and make sense of.

For example - Stack multiple ansistring values into one long ansistring - with a means to tell where each begins and end - effectively allowing this arbitrary amount of data to be sent in one message eliminating semaphore code overhead processing a bunch of little messages.

Even this would require overhead - where as set message definations may be a better solution - which - to my knowledge implies writing my own simpleipc unit by a different name, and then writing the code the Win32 implementation and then the unix implementation myself.

So - I guess I'm asking a couple things:

1: Would anyone would be opposed to me extending the simpleipc class minimally - and submitting it to the fcl for distribution - so that it has the two new procedures/function mentioned above? (which I would need to know the procedure for doing that or be sent to a resource so I can learn how this is done for quality control etc.)

2: Is IPC the best method for this type of DATA communication between processes? So far I think IPC would be better because its my understanding that it happens all in memory. No disk i/o - therefore faster. Speed is definitely the goal here.

I never used a PIPE - but I've read enough to know that PIPES might be the way to go, and TCP IP is another.

Best Regards,
And thanks to the Free Pascal Community for your help so far. Jason Sage

I've just performed more tests using the stock simpleipc - and the SendMessage and GetMessage - though defined as "STRING" (Which I thought had a max length) seems to be able to support huge ansistrings.

This - implies that no changes are probably necessary. Though I'm a bit perplexed about how I can make send an ansistring that is 1 megabyte through a procedure/function pair - declared as only String - I hope this won't make the application that may do this a bit "shaky" from writing to memory I shouldn't be.

My test app is a modified version of the fcl demo/example ipcclient: (The only new code is the declaration of the ansistring and the loop (and i:integer var) to make it rather big - a kludge - but fine for proof of concept testing. Note: I have my fpc configuration to only use 32 bit integers and to allow the plus equal construct MyVari += 1;

--- CODE BEGIN ----

{$mode objfpc}
{$h+}
program ipcclient;
uses simpleipc;
var sa: Ansistring;
   i: integer;
begin
  sa:='';
  for i:=1 to 100000 do sa+='1234567890';
  With TSimpleIPCClient.Create(Nil) do
    try
      ServerID:='ipcserver';
      If (ParamCount>0) then
        ServerInstance:=Paramstr(1);
      Active:=True;
      SendStringMessage(sa);
      Active:=False;
    finally
      Free;
    end;
end.

--- CODE END ----

This may be great news!

Jason P Sage

Jason P Sage wrote

I've just performed more tests using the stock simpleipc - and the SendMessage and GetMessage - though defined as "STRING" (Which I thought had a max length) seems to be able to support huge ansistrings.

Well, RTFS:

|unit simpleipc;
|
|{$mode objfpc}{$H+}
|
|interface

There's the {$H+} in it, so String actually is an AnsiString already, no ShortString anymore.

Vinzent.

Why not use TCP/IP to send informations from one program to another ? In Linux this should perform at least as well as anything else, in Windows named pipes or windows messages with "attached" shared memory blocks might perform better.

Moreover you now easily can split the application between multiple machines.

-Michael