IPC Functionality - - Named Pipes...???

[KeithW]

Greetings,

Does A5 support "named pipes" or another way of providing 2-way Inter- Process Control?

Regards,
Keith

[Scott Emerick]

Keith,

I have no clue what a "Named Pipe" is other then like PVC :)

Can you describe what you want to do exactly, maybe others would then know how to respond. I personally don't know what your meaning of 2-way Inter- Process Control is, but it sounds to me like the answer will be yes.

Scott

[AaronBBrown]

Alpha has no direct support for IPCs. I am also interested in what you are trying to do in Alpha that would require this functionality.

We do however have a full winsocket functionality that could be used to mimic certain aspects of IPC if absolutely needed.

[KeithW]

Keith,

I have no clue what a "Named Pipe" is other then like PVC :)

Can you describe what you want to do exactly, maybe others would then know how to respond. I personally don't know what your meaning of 2-way Inter- Process Control is, but it sounds to me like the answer will be yes.

Scott

Scott,

Thanx for the quick PVC laugh...

Lets take a simple example of a pipe, in bigger OSes like unix (MS-DOS and Windows has implementations... is DOS days it was really implemented via the file example below, though) you can send data from the Standard Output (typically the video) of program1 to the Standard Input (typically keyboard) of program2 by issueing a command line stucture of:

program1 | program2

You could of couse save the data stream to a file and doing the same thing by typing these two commands...

program1 >/tmp/savedata
program2 </tmp/savedata

the main problem is that you generate a file that:
a) has to be cleaned up and
b) makes what you are doing insecure.

Yes, usually everything happens so fast and you would have to know exactly where to look to find out what is going on here. But, the two points above still remain.

Named Pipes up the stakes. First of all you can establish 2-way communications between programs must like TCP/IP sockets however, for on the same machine use, to the best of my knowledge, networking in NOT needed and secondly unlike the examples I used above (program1 | program2) they provide 2-way communication.

I can write a program that does something "very" specific and then write my database application and with a named-pipe should be able to establish 2-way communications with my program (database or via other languages) that also support named-pipes.

Another benefit that I believe also exists, I avoid firewall issues, too.

If you establish a named-pipe accross systems (read as networks) you invoke networking issues, but if not, then the OS handles all the details of letting two processes talk to each other.

Regards,
Keith

[KeithW]

Alpha has no direct support for IPCs. I am also interested in what you are trying to do in Alpha that would require this functionality.

We do however have a full winsocket functionality that could be used to mimic certain aspects of IPC if absolutely needed.

Aaron,

Trying to avoid sockets and requiring tcp/ip to be setup and working.
Avoid firewall issues, yet allow two-way communications. At this point the idea is still in the early stages so I would rather not be too specific of why I want this... I am very sure you understand the technology with no further explaination though.

If you really feel you need more info, contact me off-phorum.

Regards,
Keith

[Blake]

I did a lot of work with named pipes back when they were hot stuff (ca. '96/'97 :D ) to hook up Windows and OS/2, and they're really quite cool. You can essentially connect any two processes, regardless of where they are (both local, one remote) and regardless of the protocol used.

Using them in A5 wouldn't require anything more exotic than any other OS call, and there are many examples of that.

How I would do it is build a DLL that your A5 could activate in a very high-level, contractless way. In other words, your A5 app starts and it calls your DLL's "Connect" routine (no parameters if you can avoid it). Then just have a send routine and a receive routine that passes strings back and forth. Let the DLL handle all the hard work. (You might even want to skip the Connect call and just have the DLL accept sends and receives and connect/disconnect on its own.)

You might even be able to find a DLL that does this, or for sure could find a lot of sample code.

[KeithW]

...

How I would do it is build a DLL that your A5 could activate in a very high-level, contractless way. In other words, your A5 app starts and it calls your DLL's "Connect" routine (no parameters if you can avoid it). Then just have a send routine and a receive routine that passes strings back and forth. Let the DLL handle all the hard work. (You might even want to skip the Connect call and just have the DLL accept sends and receives and connect/disconnect on its own.)

You might even be able to find a DLL that does this, or for sure could find a lot of sample code.

Blake,

How would you do the first part in A5? Since I have never written DLL's before this part is new to me. I have the other end covered, I just need to get the communication established from A5. I need to be able to send and receive buffers upto 1K, however most would be 256 bytes of less.

Regards,
Keith

[AaronBBrown]

You also might check to see if there is an OLE implementation of the IPC functions. If so, find some sample Visual Basic code and it shouldn't be too difficult to implement in A5. Otherwise, you will be stuck writing declare and declarestruct in Alpha Five.

[KeithW]

You also might check to see if there is an OLE implementation of the IPC functions. If so, find some sample Visual Basic code and it shouldn't be too difficult to implement in A5. Otherwise, you will be stuck writing declare and declarestruct in Alpha Five.

Aaron,

Thanx for the idea, any idea where I might search for such a item as an "OLE implementation of the IPC functions?"

Native "naned pipes" would be MUCH easier though...

Regards,
Keith

[AaronBBrown]

I'd try googling for "OLE IPC" or something. Maybe check msdn.microsoft.com, also, but google should catch that.

Yes, native named pipes would probably be easier, however it would take some work to implement them in Alpha Five and I think you're the first person to ever ask for them. :)

I'd still suggest using sockets since every machine made since 1997 or so should have TCP/IP installed by default.

Aaron,

Thanx for the idea, any idea where I might search for such a item as an "OLE implementation of the IPC functions?"

Native "naned pipes" would be MUCH easier though...

Regards,
Keith

[Marcel Kollenaar]

Greetings,

Does A5 support "named pipes" or another way of providing 2-way Inter- Process Control?

Regards,
Keith

Hi Keith,

I made some small steps in Serial I/O in Xbasic and discovered that it will be a difficult job. You'll need to call API functions. In Xbasic you can do that but it takes a long breath to get them working. I can't say it can't be done in Xbasic, because I have no knowledge of all the Xbasic possibilities. The biggest problem I encounter is the use of Threads. Xbasic knows them but I can't use them because part of the thread functions are for A5 internal use. And the functions that are documented are not sufficient. I tried to translate some C-threaded functions into Xbasic but got stuck at the CallBack() functions. Xbasic can't handle this. Or at least I haven't found a way to get them working... But you can use functions like WaitForSingleObject(), CreateNamedPipe(), ReadFile() etc.

In the Windows "Platform SDK: Interprocess Communications" there are examples like: "Multithreaded Pipe Server", Transactions on Named Pipes. I would suggest to download the Windows SDK 2003.

Therefore I agree with Blake. Build it in a programming language outside A5 and create a dll. Try to make the API-calls as simple as possible.

Good Luck.

Marcel

[Blake]

How would you do the first part in A5? Since I have never written DLL's before this part is new to me. I have the other end covered, I just need to get the communication established from A5. I need to be able to send and receive buffers upto 1K, however most would be 256 bytes of less.

Writing a DLL isn't difficult but A5 can't build them (AFAIK). It's not much different from writing any other code.

The only challenge with named pipes is getting all the parameters right (do you want a full-duplex pipe, multiple pipes on the same machine, etc). Is it two A5 apps that are going to be communicating? I'm trying to envision the code and how it would go.

Ideally, I'd think you'd want something like:

Data = IPCListen(pipename)
Response = Dosomethingwith(Data)
IPCSend(Data)

Something that would work on both ends simply. Hmm. Lemme look around and see what I have.

[KeithW]

Writing a DLL isn't difficult but A5 can't build them (AFAIK). It's not much different from writing any other code.

The only challenge with named pipes is getting all the parameters right (do you want a full-duplex pipe, multiple pipes on the same machine, etc). Is it two A5 apps that are going to be communicating? I'm trying to envision the code and how it would go.

Ideally, I'd think you'd want something like:

Data = IPCListen(pipename)
Response = Dosomethingwith(Data)
IPCSend(Data)

Something that would work on both ends simply. Hmm. Lemme look around and see what I have.

Blake,

What I would like to do is have my A5 application talk to a program in another language, as I do not have sufficient A5 skills to migrate it at this point in time. The ability to handle multiple connections is desirable, but I suppose could be initially avoided.

full duplex and accross network would be highly desirable.

The other program functions in a "black box" manner, I need to:

connect,
pass some data-in,
get a response,
disconnect...

I would like to leave the other program running as a "service" type of facility, start it if it isn't running, leave it running when finished. It is possible that multiple clients would try to connect at the same time, I would think no more than 2 or 3 even on a busy 25+ user network environment and the transactions, for lack of a better word, should run in no more than 1 or 2 seconds in the worst case, mostly under a second.

Any pointers would be most greatfully appreciated...

A minor concern I have run accross is that it appears that "named pipes" do not work on the Windows 95/98/ME workstations. Is that true or did I read something out of context?

Regards,
Keith

[Blake]

What I would like to do is have my A5 application talk to a program in another language, as I do not have sufficient A5 skills to migrate it at this point in time. The ability to handle multiple connections is desirable, but I suppose could be initially avoided.

Ah. So, there are many, many ways to do this. Named pipes is one of the coolest but you might want to look at all the options before deciding. I mean, the simplest, obvious way to do this is to use actual files. You know, share a directory, have both programs watch the directory, have the programs process the files that they are supposed to while putting their responses back.

This is simple and surprisingly fast, but admittedly not as cool as pipes.<s>
In fact, the thing about pipes is that they are treated very much like files. StdIn and StdOut are the names of the pipes used for console work, as you know.

full duplex and accross network would be highly desirable.

Google CreateNamedPipe to get a sense of the call you're working with.

The other program functions in a "black box" manner, I need to:

connect,
pass some data-in,
get a response,
disconnect...

How do you pass the data to your black-box?

I would like to leave the other program running as a "service" type of facility, start it if it isn't running, leave it running when finished. It is possible that multiple clients would try to connect at the same time, I would think no more than 2 or 3 even on a busy 25+ user network environment and the transactions, for lack of a better word, should run in no more than 1 or 2 seconds in the worst case, mostly under a second.

I don't see it as a huge problem. Pipes are cheap to create. I could probably find an example around here somewhere to send you.

A minor concern I have run accross is that it appears that "named pipes" do not work on the Windows 95/98/ME workstations. Is that true or did I read something out of context?

It is true. NT and its inheritors (Win2K, WinXP) have named pipes but not any of the DOS-based versions. All that it means is that your server--the one that creates the pipe--can't be Win9x or earlier. (The context in which I used named pipes most intensively was OS/2 connecting to Win3.1.)

The client side treats the pipe like a file, so it doesn't matter--you could do it in DOS. It's all reads and writes.

[KeithW]

Blake,

I have used file watching in directories before and could do that in a heartbeat, however the data I am passing is sensitive and aside from nosey prying, and don't want any leftover pieces when something dies as that is going to happen no matter not desiring it, it will happen just the same.

I understand the pipes as I come from a Unix background. I also have access in the other development tool (Windows based) to create and use "named pipes" which is how I tested my (black box) component. Now I want to interface it with my A5 application.

Currently using the other tool to test my "black box", I create the pipe, I load a buffer and write it to the pipe. Receive the data in a buffer and parse as needed. Load the O/P buffer and pass it back. As I said before, the max is 1K, however it is normally less than 256 bytes. In the other tool I have both Client and Server pieces working.

I am hoping that I do not have to deal with a Win9x/ME workstation trying to play server (even peer level) this could be an Ace-in-the-hole. I might just get to avoid Win9x/ME regardless of whether A5 runs there or not.

Any examples would be appreciated... I'm not really a VB programmer and I've been away from C for years... that is the problem with RAD/4GL environments, once you get away from the details and when you run into an area that the RAD/4GL does not handle then you have to pick up the shovel and dig...I'm just way out of practice....

Thanx,
Keith