The following Rpc Call get_messages(1, MESSAGES&)

Should give me the 1e sequence number, but it gives met 39695 - 41747 always 2000 in total.

It seems there is a 2000 line buffer, but only the last entry's are read back.

Any hints.

There is no way to get all the messages, because they aren't there anymore. Once the client writes the 2001st message, it deletes message 1 from memory.

---

There is no way to get all the messages, because they aren't there anymore. Once the client writes the 2001st message, it deletes message 1 from memory.

That's what I expected, but better to know it for sure.
Thanks for the info

Does this RPC return the WUs that are in the process of downloading too?
I figured it was simplier to ask here then dig thru the source or try to catch a WU download in progress.
Thanks for any help
--Mike

Hi Fred..
I managed to get an RPC added that is most useful for messages.

Send this RPC 'get_message_count'
It will return in the seqno tag the total amount of messages on that host.
Trying to read 2000 messages will usually hang up.
Once you know what the total is, you can decide on how many to list from N to the message_count. (msg_cnt - n)
I do 100 in Boinc.NET
Hope this helps.
--Mike

I've never seen any problems with downloading messages.
I only missed the 2000 part, but I got that worked out.
I don't use the new command at all. This only adds to all sorts of compatibility problems.

Does this RPC return the WUs that are in the process of downloading too?
I figured it was simplier to ask here then dig thru the source or try to catch a WU download in progress.
Thanks for any help
--Mike

It is. Upload and Download all are WU. In fact everything is included, from beginning to the end.

I've never seen any problems with downloading messages.
I only missed the 2000 part, but I got that worked out.
I don't use the new command at all. This only adds to all sorts of compatibility problems.

Its all good..
I dont know why some are running versions as old as 6.5.x
The new versions can even tell you if there is an ATI or nVidia card present.
I just tell the users that if they want this info to be visible, they need to update BOINC. The code dont care.
My program checks to see if the get_message_count works and defaults back to reading what ever the user has set for 'after n'. (a dropdown Combobox).
I have tested Boinc.NET with 50 hosts(duplicates of existing but it still has to read the data on each update) and the only issue I have ever had is with getting the messages. I can read a one meg client state but huge message buffers stop after 500-800 lines. Its not the coding.. I think it is happening at the client for some reason.
Do you have any ideas on what I may be doing wrong?
Im looping on the TCP xfer and this works great with any other RPC no matter the size returned. Its not the grid or binding source the data is going in to. Either can hold millions of rows. Besides, if this was an issue, an expection would be thrown.
Oh well.. Most users have elected to update in favor of getting the new features that pre 6.10.x versions dont.

Now to start adding logging.
Boat load of ways to do this but which makes the most sense?
Im actually thinking of logging to a server where users can access this from anywhere they can get online. It would be sweet to check on your farm using an iPhone :)
Never a dull moment.. lol
Happy Programming!
--Mike

I've never seen any problems with downloading messages.
I only missed the 2000 part, but I got that worked out.
I don't use the new command at all. This only adds to all sorts of compatibility problems.

Its all good..
I dont know why some are running versions as old as 6.5.x
The new versions can even tell you if there is an ATI or nVidia card present.
I just tell the users that if they want this info to be visible, they need to update BOINC. The code dont care.
My program checks to see if the get_message_count works and defaults back to reading what ever the user has set for 'after n'. (a dropdown Combobox).
I have tested Boinc.NET with 50 hosts(duplicates of existing but it still has to read the data on each update) and the only issue I have ever had is with getting the messages. I can read a one meg client state but huge message buffers stop after 500-800 lines. Its not the coding.. I think it is happening at the client for some reason.
Do you have any ideas on what I may be doing wrong?
Im looping on the TCP xfer and this works great with any other RPC no matter the size returned. Its not the grid or binding source the data is going in to. Either can hold millions of rows. Besides, if this was an issue, an expection would be thrown.
Oh well.. Most users have elected to update in favor of getting the new features that pre 6.10.x versions dont.

Now to start adding logging.
Boat load of ways to do this but which makes the most sense?
Im actually thinking of logging to a server where users can access this from anywhere they can get online. It would be sweet to check on your farm using an iPhone :)
Never a dull moment.. lol
Happy Programming!
--Mike

I have 2000+ on my computers most of the time, even as I reboot them every day.
No problems whatsoever to pull the 2000 lines at once.
And waiting for exceptions is not always wise. The program can run without giving any beep, but still mess up the system pretty well. e.g. by not releasing handles or resources. So many things can go wrong....
Everything you don't know exactly why it doesn't work can get you into serious problems.
Updating is not always wise, when it works it works. All new things will get you into new problems.

[quoteI have 2000+ on my computers most of the time, even as I reboot them every day
No problems whatsoever to pull the 2000 lines at once..[/quote]
Thats nice. Hows that help me?

And waiting for exceptions is not always wise. The program can run without giving any beep, but still mess up the system pretty well. e.g. by not releasing handles or resources. So many things can go wrong....
Everything you don't know exactly why it doesn't work can get you into serious problems.

Awww common.. Anything worth while is worth waiting for! You kidding Right?
That is NOT what I said. I said if the grid or binding source ran out of space an exception would be thrown.

Updating is not always wise, when it works it works. All new things will get you into new problems.

Thats not up to me, or you.. its up to the users. Like I said, They can update and get all the info thats there OR.. use the old BOINC and get only what its aware of. I myself like to keep Boinc.NET in tune with what the new version of BOINC has to offer. Like the 'have_cuda' and have_ati'. Users wanted it so its there for them. I really like the line in red above. It reminds me of every OS Micro$oft has released.. :)

BTW.. thanks for the info on the get_message_transfers Fred
Peace
--Mike

I dont know why some are running versions as old as 6.5.x

I'm using 6.2 because I have no intention to use my GPU for crunching, and I don't want all the new bugs that were introduced along with GPU support.

---

I dont know why some are running versions as old as 6.5.x

I'm using 6.2 because I have no intention to use my GPU for crunching, and I don't want all the new bugs that were introduced along with GPU support.

Very wise. If it works it works.