Inter-script communication possible?

[stigma]

Hey,

I was wondering if anyone could tell me if it is possible to program messages that go from one script to another. For example I would like one script1 on PC1 to react to an event, and then send a message of some sort to script2 on PC2 so it can react to it. Is there any way to do this?

If there is no better way of doing it, then I've been pondering if it would be doable via writing to a file, ana having the other script read from the same file on the network to pick up new messages as they come. I wil have to learn how read/write to general .txt files first tho hehe

I hope someone has faces this situation before and can tell me if there is a direct way of doing what I need.

-Stigma

[flyingboz]

Hey,

I was wondering if anyone could tell me if it is possible to program messages that go from one script to another. For example I would like one script1 on PC1 to react to an event, and then send a message of some sort to script2 on PC2 so it can react to it. Is there any way to do this?

Lots of ways to skin the cat. This has been hashed intermibly in the forums. Many things can be used as a semaphore (file, registry, network); it all depends on how you want to implement your specific issue.

You may also wish to investigate windows messages

[stigma]

Im pretty fresh still, so for right now i'd be satisfied with anything that work, or any example that I might be able to replicate really hehe.

Writing to/reading from file seems like the best way to go if you can't send send/recive directly from the scripts tho.

If anyone knows some example code for something like that, or a good thread on it, I would appreciate a linkup. Its not so easy to find this tuff in a search apparently.

-Stigma

[RulerOf]

Im pretty fresh still, so for right now i'd be satisfied with anything that work, or any example that I might be able to replicate really hehe.

Writing to/reading from file seems like the best way to go if you can't send send/recive directly from the scripts tho.

If anyone knows some example code for something like that, or a good thread on it, I would appreciate a linkup. Its not so easy to find this tuff in a search apparently.

-Stigma

While I can't provide you with example code because the script I'm working on isn't finished yet, one very simple way to communicate with a script on another computer is simply writing to a file with one script and then reading the file with another. Simple FileWriteLine() to \\<computer>\<share>\<file>.txt could work well.

One question I actually have, as I am implementing this myself, is, does anyone know if you run into sharing or access violations if one script has the file open while others try to access or overwrite it?

[flyingboz]

...[Do] you run into sharing or access violations if one script has the file open while others try to access or overwrite it?

Depends on how the file is opened. You can do some research on "windows file locking". Suffice it to say that if you have people deleting, writing garbage, or otherwise mucking with your file, undesired results can occur.

That being said, FileOpen() does not utilize (or expose) locking mechanisms -- you can open a file for reading or appending an arbitrary number of times.

[tAKTelapis]

Here you go guys, got bored, and felt like submitting and example, its very crude, but it works.

i did it with 2 different scripts, this way, you can have the Reciever running on 1 machine, and the sender running on another:

Message Sender:

Set the local monitor file to the location of an ini file, just make sure it exists (file > save as in notepad make it a .ini)

then SHARE the directory with READ/Write Access

(i actually ran this locally as is.. worked fine)

$LocalMonitorFile = "c:\test\monitorfile.ini"
$MessageToSend = InputBox("Message", "Input the message to send", "")
IniWrite($LocalMonitorFile, "Message", 1, $MessageToSend)
oÝ÷ ØǬ±¨Eç"z÷«Iëmä^^2â¶ÅW­¢Ø^²«y©Ý~)^©Ê­æ­y×®X­«­¢+ØÀÌØíIµ½Ñ5½¹¥Ñ½É¥±ôÅÕ½ÐíèÀäÈíÑÍÐÀäÈíµ½¹¥Ñ½É¥±¹¥¹¤ÅÕ½Ðì()]¡¥±Ä($ÀÌØíµÍÍô%¹¥I ÀÌØíIµ½Ñ5½¹¥Ñ½É¥±°ÅÕ½Ðí5ÍÍÅÕ½Ðì°ÅÕ½ÐìÄÅÕ½Ðì°ÅÕ½ÐìÅÕ½Ðì¤($%%MÑÉ¥¹1¸ ÀÌØíµÍͤôÀQ¡¸($$%
½¹Ñ¥¹Õ1½½À($%±Í%MÑÉ¥¹1¸ ÀÌØíµÍͤÐìÀQ¡¸($$%5Í  ½à À°ÅÕ½Ðí5ÍÍÅÕ½Ðì°ÀÌØíµÍͤ($$%%¹¥]É¥Ñ ÀÌØíIµ½Ñ5½¹¥Ñ½É¥±°ÅÕ½Ðí5ÍÍÅÕ½Ðì°ÅÕ½ÐìÄÅÕ½Ðì°ÅÕ½ÐìÅÕ½Ðì¤($%¹%)]¹

Result should be, that you can run the Message Sender script from anywhere on the network, and it will make which ever machine is running the Reciever script throw up a message box with the text you used as input.

[stigma]

Since I got the first answer here earlier I sucessfully implemented a very simple network filebased messaging system. it seems to work fine.

There IS one very big problem however...

The autoit write methods do not seem to lock down the file that it writes to.

That creates a ticking timebomb problem. The simple messages I send back and forth now are so small and quick to read/write that it probably takes less than a 1ms. Thus, if I check for new messages every 100ms the chances that script1 reads the file while script2 is in the middle of writing to it is very small. However... given enough time it is definately going to happen, and then the whole house of cards will come tumbling down and youl have either a windows error (probably not), or just some really random results by reading a half-written line or something.

Is there a way around this? Any way to make the method lock the file while writing or reading? what we need is a mutex lock, but how can you do that without access to atomic operations somehow?

oh, and BTW, can soneone tell me how I can DELETE a line of text from a .txt? Right now I cannot for the life of me I cannot figure how to delete text. All I can do is either append more text, or delete the whole file hmm...

-Stigma

[RulerOf]

IniWrite() will actually create the .ini file if it doesn't already exist. My script actually deletes the ini file if it exists already, and then adds lines to it.

Also, Flyingboz, thanks for the info. I'll see if that works out properly...

I'm actually working on trying to encode several types of information into a text file. I don't think that a standard ini file is appropriate, and an epiphany told me that some type of XML format would be perfect... now the question is how easy will parsing XML in autoit be

[RulerOf]

Since I got the first answer here earlier I sucessfully implemented a very simple network filebased messaging system. it seems to work fine.

There IS one very big problem however...

The autoit write methods do not seem to lock down the file that it writes to.

That creates a ticking timebomb problem. The simple messages I send back and forth now are so small and quick to read/write that it probably takes less than a 1ms. Thus, if I check for new messages every 100ms the chances that script1 reads the file while script2 is in the middle of writing to it is very small. However... given enough time it is definately going to happen, and then the whole house of cards will come tumbling down and youl have either a windows error (probably not), or just some really random results by reading a half-written line or something.

Is there a way around this? Any way to make the method lock the file while writing or reading? what we need is a mutex lock, but how can you do that without access to atomic operations somehow?

oh, and BTW, can soneone tell me how I can DELETE a line of text from a .txt? Right now I cannot for the life of me I cannot figure how to delete text. All I can do is either append more text, or delete the whole file hmm...

-Stigma

Not sure on how to delete the line, sorry.

To avoid your issue with simultaneous file read/writes, you could, for example, create a "locking marker" of sorts, either in the same file or in a different one.

Imagine, if you will, that during your write operation to "MessageFile.txt," you have a flag set in "FileLock.ini" that says "MessageLock.txt is currently in use," every time your scripts read or write the file. That way, if one script is doing a read, it sets the locking flag. Your other script would go to write to that file, but when it attempts the write, it'll see that the locking flag is currently set, so it waits a random amount of time (i.e. 100ms) and checks the flag again. Once it sees the flag has been cleared, it sets the flag itself, and then performs its operation.

Of course, you could run into problems if both scripts attempt to either set or clear the flag at the same time, but that can be taken care of with either multiple flags or ini files... look into how CRC's or some other type of error checking algorithms to get an idea as to how this stuff works.

[ramble]

Hell, you could even make a file with an MD5 hash of the message and then have your receiving script verify the MD5 of the message before it attempts to parse it as actual data... that might work even better

[/ramble]

I'm not an expert.

[stigma]

Ok, I just had an idea on how to code bad hack of a mutex lock for writing/reading

I don't have any code quite yet, so just listen to the idea:

We have 2 files:

The message file - Containing all the messages or whatever you want to transfer

The Read lock file - A simple .txt with only a single character in it.

The Write lock file - A simple .txt with only a single character in it.

As we start this theory example, the writelock file exists. the readlock file does not exist.

What we do now is make the reading method check for the existance of the readlock file. This can be done easily since the method returns -1 if it cant open the file, so just just use that. if the file isnt there, and the writelock file is, that means the messagefile is marked as locked for writing, so now we can go ahead to read the message file. After we are done reading, we first create the readlock file (to make sure wedont collide with the write metod) and then delete the writelock file.

Now simultaniously, the writing method on hte other PC is continously checking for the existence of the writelock file. After it sees that it has disappeared (and the readlock file is also back), we can go ahead to the message file without fear of collision because the writelock file exists and makes sure the reading method does not attempt to read. After we have written to the file, we create the writelock file, and then delete the readlock file.

We get 2 very nice things from this system:

1 - We effectively have a mutex (mutually exclusive) lock on the message file, so we can never get error or corrupted data

2 - Instead of having to check the message file over and over again continously to see if ther are any new messages, we can now instead just check for the existence of the readlock/writelock files, which is much much faster (I would assume). Now we have an indicator to let us know when there is new messages to be had, so this lets the read method check for messages much more reliably and with a ton less disk access.

I know its rought and poorly explined, but please give your feedback. if there a better way to do this? if you can't come up with any suggestions I will give it a go and see how it works

-Stigma

Edited February 7, 2007 by stigma

[stigma]

Not sure on how to delete the line, sorry.

To avoid your issue with simultaneous file read/writes, you could, for example, create a "locking marker" of sorts, either in the same file or in a different one.

Imagine, if you will, that during your write operation to "MessageFile.txt," you have a flag set in "FileLock.ini" that says "MessageLock.txt is currently in use," every time your scripts read or write the file. That way, if one script is doing a read, it sets the locking flag. Your other script would go to write to that file, but when it attempts the write, it'll see that the locking flag is currently set, so it waits a random amount of time (i.e. 100ms) and checks the flag again. Once it sees the flag has been cleared, it sets the flag itself, and then performs its operation.

Of course, you could run into problems if both scripts attempt to either set or clear the flag at the same time, but that can be taken care of with either multiple flags or ini files... look into how CRC's or some other type of error checking algorithms to get an idea as to how this stuff works.

[ramble]

Hell, you could even make a file with an MD5 hash of the message and then have your receiving script verify the MD5 of the message before it attempts to parse it as actual data... that might work even better

[/ramble]

I'm not an expert.

I started to write on my idea before I got to read this, but yes - you seem to have the same basic idea.

I'm wondering though, what would be the quicker operation to do...

On one hand, deleting/creating the files are probably a little slower than opening a file and changing a single character and closing it again.

On the other hand, the creating/deleting of files won't be done more often than messages are sent, but using .ini's the files will have to be opened,read and closed once every refresh when you look for new messages. I have a suspicion that might actually cause a lot more unnessecary diskreading than my method, but I am uncertain.

Any thoughts on that before i start coding something?

-Stigma

[RulerOf]

When creating a messaging app like both of us are, it's more than ideal to utilize the least amound of disk reading/writing as possible. Unfortunately, I simply can't comprehend how the TCP/IP autoit libraries work, so I'm utilizing a file method.

At any rate, you're going to probably have the highest amount of disk writes with constantly creating/deleting files. Creating and deleting files involves writing/deleting header data, which could (or would) be larger than the file itself.

It really depends on the permanance of your solution.

The simple file write/reads are excellent for getting started, but due to the disk I/O which is truthfully unnecessary, it's not the best solution.

I do say though, that you/we have the right idea

[stigma]

When creating a messaging app like both of us are, it's more than ideal to utilize the least amound of disk reading/writing as possible. Unfortunately, I simply can't comprehend how the TCP/IP autoit libraries work, so I'm utilizing a file method.

At any rate, you're going to probably have the highest amount of disk writes with constantly creating/deleting files. Creating and deleting files involves writing/deleting header data, which could (or would) be larger than the file itself.

It really depends on the permanance of your solution.

The simple file write/reads are excellent for getting started, but due to the disk I/O which is truthfully unnecessary, it's not the best solution.

I do say though, that you/we have the right idea

I agree that creating/deleting files is probably relatively more resource demanding, but if you only send a handfull of messages over a minute, I think it is negible. Either way, both methods are probably more than fast enough for what is needed.

I was't even aware autoit had TCP/IP libraries. Do you have a link to the documentation for those? its probably over my head (considering I never touched autoit until a few days ago) but it might be worth checking into anyway. If the documention is good I might have a shot at it

-Stigma

[RulerOf]

Heh, i'd link to it but i have no idea where it is

Search function to the rescue, sir!

I need to go find some documentation on the XML wrapper i just found :-X