Solution For timeout exception

kartike wrote: Hi, Im getting the following error while running the sample application to upload a files into cloud. "The request timestamp was outside the valid time window" when i do change the system time GMT+2.It will work correctly no exception thrown. i dont want to make changes in system time.when i run the sample in another system i need to change the system time again.I dont want to do like that. I need to change date and time coding itself using c#. Please can you give me a solution.. Regards, Karthik.

Hi karthik,

Please see my solution in

https://community.emc.com/docs/DOC-10621

Basically, you issue a dummy request to the server to get its time stamp and calculate your times from that value

Hi ,

Sorry i studied that document.I coundn't understand it.

I am using the code C#.

Can u please give me a solution in C#?

Regards,

Karthik

I won't be able to give you an actual C# example until I return on Tuesday from holiday. Essentially, make a web request to http://server/rest and read the "date"

Response header. You then use that date as a basis for computing the date for your requests. O

Hi

These are the steps i have followed to create sample,

            const string host = "cloudonestorage.peer1.com";
            const int port = 443;
            const string userName = "";
            const string secret = "";

            EsuRestApi cloudRest = new EsuRestApi(host, port, userName, secret);         
            UploadHelper upload = new UploadHelper(cloudRest);
            ObjectId objectId = null;
            objectId = upload.CreateObject("C://Users//karthike//Desktop//Element.docx", null, null);   

How can i make a we request to server and get the date?

Hi, How can i get the response header date using C#?

Can you please give me a solution?

Thanks,

Karthik E.

Hi,

I gave the web request and get the response header date.

header date is like : Tue, 06 Sep 2011 04:29:18 GMT

My local sytem time is like: Tue, 06 Sep 2011 04:22:32 GMT

Now i need to add 7 min to local time and then add that value to header in following code in EsuRestApi.cs,

                DateTime dateHeader1 = DateTime.Now.ToUniversalTime();
                dateHeader1.AddMinutes(7);
                string dateHeader = dateHeader1.ToString("r");

              
                log.TraceEvent(TraceEventType.Verbose, 0,  "Date: " + dateHeader );
                headers.Add( "Date", dateHeader );

Is this Right? I followed tihs procedure.I can get the same timeout error.Did i do anything wrong?

Is there any other way to adjust the outgoing request timestamp?

How can i adjust the outgoing request timestamp?

Please give me a solution.

Regards,

Karthik.

Hi Karthik,

Try:

                DateTime dateHeader1 = DateTime.Now.ToUniversalTime();
                dateHeader1 = dateHeader1.AddMinutes(7);
                string dateHeader = dateHeader1.ToString("r");

              
                log.TraceEvent(TraceEventType.Verbose, 0,  "Date: " + dateHeader );
                headers.Add( "Date", dateHeader );

DateTime objects are immutable.

I'm working on getting this built-in to the dotnet API.

Karthik,

Can you check out the latest version of EsuRestApi.cs from subversion?  I added a CalculateServerOffset() method and a ServerOffset property.  You can insert the following code at startup:

EsuRestApi api = new EsuRestApi(...);
api.ServerOffset = api.CalculateServerOffset();

Hi Jason,

Do you think this solution works for Load balanced ATMOS servers having different time? Is the ATMOS server time supposed to be a fixed value?

Thanks,

Ravi

Ravi,

All Atmos nodes are set to UTC time.  A load-balanced cloud with endpoint inclusions in different time zones may exhibit different latencies for different RMGs/locations.  This method simply pings the endpoint and uses the date stamp in the response to calculate the offset.  It's as good as any other method I can think of to determine offset.  A signed request should have a validity window of +/- 5 minutes.  As long as the client and Atmos nodes are synced to accurate time servers, there shouldn't be any issues.

- Stu