Right now, I'm using named pipes which are unidirectional on unix.
So, I need 2 of them to make a bi-directional communication.
Well, so far, no problem.
I have a well known named pipe in which the Root_Server is always listening to, waiting for MML messages to came in.
And then, the Root _Server is supposed to make the message's action and issue a reply, which was to be also to another well know named pipe.
And here is the problem.
If I have, let us say, 4 browsers, all accessing the page that initiates a communication between the User_Interface and the Root_Servers (the main element of the application), How do I guarantee that the answer received is the one corresponding to the message sent, if all go and come by the same named pipes?
Well, I could devise a sort of handshaking protocol that would see if the message received was indeed the one that corresponded to the message sent and only then send an acknowledge message to release it and consider it delivered but I DID KNOW then that in that way I was heading for trouble! A very complex communication protocol, with a high overhead just to perform a simple communication....
So I left the office without a solution that satisfied me and, in the way to home suddenly it stroke me!
I don't need any of that!
What I need is to create a random named pipe BEFORE sending the message to the Root_Server and add a TAG in the MML language to carry that information!
In that way, I can have as many different communications as I like as the return message will always be send correctly to the right waiting routine!
Part of the development phase is just this; to find out solutions that not only work and do the job pretended as be simple and clear as well!
Yesterday I went to the office and I debugged the code I wrote at the end of the day to create a MML message from the given elements (the same ones that are delivered, when the MML message is parsed) and although I still have to write 2 routines (they are important but not indispensable for the first tests), so I only have to test it and if all works as I want it to, pick up on that code and write out the code to handle the generation of CCML, RRML and DCML messages.
On the parsing side, I already have the routines (in ANS FORTH) to get a contents of a container in a string, so what is lacking is the code to integrate it all.
Time is short but this is working like a pyramid.
Right now I write a lot of code and almost nothing can be seen on the user level....
But as the work proceeds, it starts to pay off.
Unfortunately, today I can't go to the office to test more code but I'll try to go tomorrow very early in the morning, if I can wake up soon enough!....
Well, I do wish a good day to you all, here in LJ land!