client code for testing interoperability
All, Yusuke provided us client source code to test the interoperability. it is now on the forge at the following URL. https://forge.gridforum.org/projects/gridrpc-wg/document/Interoperability_Te... He will also upload the revised document soon. We will wait for 2 weeks for comments and will submit it to the committee. regards. -hidemoto
Dear all,
Yusuke provided us client source code to test the interoperability. it is now on the forge at the following URL.
https://forge.gridforum.org/projects/gridrpc-wg/document/Interoperability_Te...
He will also upload the revised document soon. We will wait for 2 weeks for comments and will submit it to the committee.
I am not sure when the upgrade of GGF's Gridforge will be completed. So, I will attach the revised document for the interoperability test to this email, to save our time. After the upgrade, I will put the document on the repository and if the URL of the code changes, I will modify the document, too. Any comments for the document will be appreciated. Thanks, ----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601
Dear all, We working on standard-test.c to check the interoperability of Grid- RPC client given by Hidemoto Nakada. My first question is about the GRPC_ERROR code ? In NetSolve 2.0 we can find the following definition : #define GRPCERR_NOERROR 0 #define GRPCERR_NOT_INITIALIZED 1 #define GRPCERR_SERVER_NOT_FOUND 2 #define GRPCERR_CONNECTION_REFUSED 3 #define GRPCERR_NO_SUCH_FUNCTION 4 #define GRPCERR_AUTHENTICATION_FAILED 5 #define GRPCERR_RPC_REFUSED 6 #define GRPCERR_COMMUNICATION_FAILED 7 #define GRPCERR_PROTOCOL_ERROR 8 #define GRPCERR_CLIENT_INTERNAL_ERROR 9 #define GRPCERR_SERVER_INTERNAL_ERROR 10 #define GRPCERR_EXECUTABLE_INOPERATIVE 11 #define GRPCERR_SIGNAL_CAUGHT 12 #define GRPCERR_UNKNOWN_ERROR 13 But in the standard-test.c (I don't have grpc.h source code) I can read another error code GRPC_NO_ERROR (another syntax) GRPC_ALREADY_INITIALIZED (new error message) GRPC_NOT_INITIALIZED (another syntax) GRPC_INVALID_SESSION_ID (new error message) GRPC_NOT_COMPLETED (new error message) GRPC_NONE_COMPLETED (new error message) and so on... In the paper "The End-User and Middleware APIs for GridRPC. K. Seymour, C. Lee, F. Desprez, H. Nakada and Y. Tanaka" we have another yet error code. For example, code given page 5 with GRPC_OK and GRPC_ERROR Please, let me know where can I found the last and correct list of numeric error code of GRPC message or at least the list of error string. It should be interesting to add the list of error string into the Interoperability Testing for The GridRPC API Specification ? The grpc_error_string function should return the error description string given a numeric error code. Eddy Le 7 juin 06 à 08:03, Yusuke Tanimura a écrit :
Dear all,
Yusuke provided us client source code to test the interoperability. it is now on the forge at the following URL.
https://forge.gridforum.org/projects/gridrpc-wg/document/ Interoperability_Test_client_code_0.1/en/2
He will also upload the revised document soon. We will wait for 2 weeks for comments and will submit it to the committee.
I am not sure when the upgrade of GGF's Gridforge will be completed. So, I will attach the revised document for the interoperability test to this email, to save our time. After the upgrade, I will put the document on the repository and if the URL of the code changes, I will modify the document, too.
Any comments for the document will be appreciated.
Thanks,
----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601 <gridrpc-interoperability-0604.rtf>
------------------------------------------------------------------------ ---------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------ ------------------------
Hi, Eddy,
Please, let me know where can I found the last and correct list of numeric error code of GRPC message or at least the list of error string.
The error code list in this document is the latest. http://www.ggf.org/documents/GFD.52.pdf The error codes such as GRPC_OK and GRPC_ERROR are obsolete. NetSolve 2.0 is not perfectly GridRPC compliant, I think, only old error codes are implemented. However, you can try the latest GridSolve which is almost complete reimplementation of NetSolve and GridRPC compliant.
It should be interesting to add the list of error string into the Interoperability Testing for The GridRPC API Specification ? The grpc_error_string function should return the error description string given a numeric error code.
Thanks for your comment. standard-test.c contains error_report_test_1 for this purpose, though the test result should be checked by testers' eyes because the description will be various. Is it not enough for you? Thanks, ----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601
Hi Yusuke Tanimura, Thank you very much. We continue to validate the Interoperability Testing API Specification with the DIET implementation. Keep in touch. Best regards, Eddy Le 16 juin 06 à 08:16, Yusuke Tanimura a écrit :
Hi, Eddy,
Please, let me know where can I found the last and correct list of numeric error code of GRPC message or at least the list of error string.
The error code list in this document is the latest. http://www.ggf.org/documents/GFD.52.pdf
The error codes such as GRPC_OK and GRPC_ERROR are obsolete. NetSolve 2.0 is not perfectly GridRPC compliant, I think, only old error codes are implemented. However, you can try the latest GridSolve which is almost complete reimplementation of NetSolve and GridRPC compliant.
It should be interesting to add the list of error string into the Interoperability Testing for The GridRPC API Specification ? The grpc_error_string function should return the error description string given a numeric error code.
Thanks for your comment. standard-test.c contains error_report_test_1 for this purpose, though the test result should be checked by testers' eyes because the description will be various. Is it not enough for you?
Thanks,
----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601
------------------------------------------------------------------------ ---------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------ ------------------------
Dear Yusuke Tanimura, I give to you some news. To check the interoperability with standard- test I rewrote some structure and updated some functions due to internal problem from how we wrote the grpc_function_handle_t structure. In your gridRPC implementation 5 functions are missing at this time. _grpc_cancel_all _grpc_get_error _grpc_probe_or _grpc_get_failed_sessionid _grpc_get_handle If you can wait again few time, I finish these functions and we can add a third middleware in your document. Best regards, Eddy Le 7 juin 06 à 08:03, Yusuke Tanimura a écrit :
Dear all,
Yusuke provided us client source code to test the interoperability. it is now on the forge at the following URL.
https://forge.gridforum.org/projects/gridrpc-wg/document/ Interoperability_Test_client_code_0.1/en/2
He will also upload the revised document soon. We will wait for 2 weeks for comments and will submit it to the committee.
I am not sure when the upgrade of GGF's Gridforge will be completed. So, I will attach the revised document for the interoperability test to this email, to save our time. After the upgrade, I will put the document on the repository and if the URL of the code changes, I will modify the document, too.
Any comments for the document will be appreciated.
Thanks,
----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601 <gridrpc-interoperability-0604.rtf>
------------------------------------------------------------------------ ---------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------ ------------------------
Dear Eddy, Thanks for the news. It will be great if we could include your test results. How many weeks does it take that you finish the implementation? Best regards,
Dear Yusuke Tanimura,
I give to you some news. To check the interoperability with standard- test I rewrote some structure and updated some functions due to internal problem from how we wrote the grpc_function_handle_t structure. In your gridRPC implementation 5 functions are missing at this time.
_grpc_cancel_all _grpc_get_error _grpc_probe_or _grpc_get_failed_sessionid _grpc_get_handle
If you can wait again few time, I finish these functions and we can add a third middleware in your document.
Best regards, Eddy
----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601
Dear Yusuke I dream one week. Two seems more probable to me. Three more realistic. When do you plan to submit ? Have you a strong dead line ? We have a meeting Tuesday to define the best way to do that quickly. To give more details, in DIET we don't have session concept. We must do something to take into account this information. Some effort around asynchronous request are required. Best Regards Eddy Le 25 juin 06 à 12:59, Yusuke Tanimura a écrit :
Dear Eddy,
Thanks for the news. It will be great if we could include your test results. How many weeks does it take that you finish the implementation?
Best regards,
Dear Yusuke Tanimura,
I give to you some news. To check the interoperability with standard- test I rewrote some structure and updated some functions due to internal problem from how we wrote the grpc_function_handle_t structure. In your gridRPC implementation 5 functions are missing at this time.
_grpc_cancel_all _grpc_get_error _grpc_probe_or _grpc_get_failed_sessionid _grpc_get_handle
If you can wait again few time, I finish these functions and we can add a third middleware in your document.
Best regards, Eddy
----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601
------------------------------------------------------------------------ ---------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------ ------------------------
Hi, Eddy, I talked to Hidemoto about the deadline. We can wait for you for three weeks. Could you finish your implementation and documentation until July 19? Thanks for your contribution.
Dear Yusuke
I dream one week. Two seems more probable to me. Three more realistic. When do you plan to submit ? Have you a strong dead line ?
We have a meeting Tuesday to define the best way to do that quickly. To give more details, in DIET we don't have session concept. We must do something to take into account this information. Some effort around asynchronous request are required.
Best Regards Eddy
----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601
Hi, OK. It's fine for me. Eddy Le 28 juin 06 à 06:13, Yusuke Tanimura a écrit :
Hi, Eddy,
I talked to Hidemoto about the deadline. We can wait for you for three weeks. Could you finish your implementation and documentation until July 19?
Thanks for your contribution.
Dear Yusuke
I dream one week. Two seems more probable to me. Three more realistic. When do you plan to submit ? Have you a strong dead line ?
We have a meeting Tuesday to define the best way to do that quickly. To give more details, in DIET we don't have session concept. We must do something to take into account this information. Some effort around asynchronous request are required.
Best Regards Eddy
----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601
------------------------------------------------------------------------ ---------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------ ------------------------
Dear Yusuke Tanimura, Good news. With the help of Abdelkader Amar (Post-doc in GRAAL), your client code for testing interoperability works fine (50 functions on 50 are done). We add this example into the next DIET release (coming soon in september). How to proceed if you want to check it before ? I can give to you an acces to a cluster with a pre- installed version of DIET and thus you can check your client ? What do you think ? Best regards, Eddy Le 28 juin 06 à 06:13, Yusuke Tanimura a écrit :
Hi, Eddy,
I talked to Hidemoto about the deadline. We can wait for you for three weeks. Could you finish your implementation and documentation until July 19?
Thanks for your contribution.
Dear Yusuke
I dream one week. Two seems more probable to me. Three more realistic. When do you plan to submit ? Have you a strong dead line ?
We have a meeting Tuesday to define the best way to do that quickly. To give more details, in DIET we don't have session concept. We must do something to take into account this information. Some effort around asynchronous request are required.
Best Regards Eddy
----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601
------------------------------------------------------------------------ ---------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------ ------------------------
Hi, Eddy,
Good news. With the help of Abdelkader Amar (Post-doc in GRAAL), your client code for testing interoperability works fine (50 functions on 50 are done). We add this example into the next DIET release (coming soon in september). How to proceed if you want to check it before ? I can give to you an acces to a cluster with a pre- installed version of DIET and thus you can check your client ? What do you think ?
That's great! As our next step, could you modify the attached document? The following items should be added, I think. - Short introduction of DIET - Notes for results of each test with DIET if you see something different - Security considerations of DIET - Author information (Eddy and Amar) - Appropriate references for DIET - Undefined behaviors if they apply to DIET Then the mailing list members can review the updated document. However, we need to mention the version numbers of each GridRPC implementation which all tests passed, in the interoperability document. This is hard to ask but is it possible for you to advance your release schedule? Best regards, ----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601
Hi, Eddy, Sorry, I forgot to attach the document.
Good news. With the help of Abdelkader Amar (Post-doc in GRAAL), your client code for testing interoperability works fine (50 functions on 50 are done). We add this example into the next DIET release (coming soon in september). How to proceed if you want to check it before ? I can give to you an acces to a cluster with a pre- installed version of DIET and thus you can check your client ? What do you think ?
That's great! As our next step, could you modify the attached document? The following items should be added, I think. - Short introduction of DIET - Notes for results of each test with DIET if you see something different - Security considerations of DIET - Author information (Eddy and Amar) - Appropriate references for DIET - Undefined behaviors if they apply to DIET Then the mailing list members can review the updated document. However, we need to mention the version numbers of each GridRPC implementation which all tests passed, in the interoperability document. This is hard to ask but is it possible for you to advance your release schedule? Best regards, ----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601
Dear Yusuke Tanimura, Please find the updated version of the document (Note: the rtf version loose the automatic contents generation, then I added by hand the section 1.3). To see which update we made please do "Find DIET" in the document ;-). I added three members. Abdelkader Amar (he do an important part of the code), Frédéric Desprez (GRAAL manager, he helps in design decision) and me. I'm in hollidays tomorrow and I will have no internet access during 15 days. If you have some questions during this time you can ask to Abdelkader Amar (Abdelkader.Amar@ens-lyon.fr) Best regards Eddy PS: Just for the fun, find the log result in log.gz file of standard_test.c with DIET.  Le 12 juil. 06 à 11:18, Yusuke Tanimura a écrit :
Hi, Eddy,
Sorry, I forgot to attach the document.
Good news. With the help of Abdelkader Amar (Post-doc in GRAAL), your client code for testing interoperability works fine (50 functions on 50 are done). We add this example into the next DIET release (coming soon in september). How to proceed if you want to check it before ? I can give to you an acces to a cluster with a pre- installed version of DIET and thus you can check your client ? What do you think ?
That's great!
As our next step, could you modify the attached document? The following items should be added, I think. - Short introduction of DIET - Notes for results of each test with DIET if you see something different - Security considerations of DIET - Author information (Eddy and Amar) - Appropriate references for DIET - Undefined behaviors if they apply to DIET
Then the mailing list members can review the updated document.
However, we need to mention the version numbers of each GridRPC implementation which all tests passed, in the interoperability document. This is hard to ask but is it possible for you to advance your release schedule?
Best regards,
----------------------------------------------------- Yusuke Tanimura <yusuke.tanimura@aist.go.jp> Grid Technology Research Center, National Institute of AIST 1-1-1 Umezono, Tsukuba Central 2 Tsukuba City 305-8568, Japan TEL: +81-29-862-6703 / FAX: +81-29-862-6601 <gridrpc-interoperability-0604-2.rtf>
------------------------------------------------------------------------ ---------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------ ------------------------
participants (3)
-
Eddy Caron -
Hidemoto Nakada -
Yusuke Tanimura