I want to get DateTime from an external reliable source. I know I can get it via DateTime.Now() Method, but that can be fooled easily by changing the Systems Date and Time. Is there a way around? It is a windows form app!
You need a Network Time Server Client class.
In short, you ask one of the numerous Time Server on Internet the date and time to set your internal PC clock using the NTP protocol.
If you search for NTP Client you will find numerous examples.
This is the first that came out from a Bing Search
Quoting:
The Network Time Protocol (NTP) and its simplified form (SNTP) are widely used to
synchronize network resources, due to their simplicity and effectiveness.
Of course, as everything installed on a client PC, also this could be hacked faking the address of the time server and returning a different value. But this will require more work from the hacker than simply resetting the PC clock.
While you might implement a Network Time Protocol client in your app and request the current time over the net or request something from some http server and use the time from Date response header, this also may be fooled (the one may intercept the traffic and send you responses on behalf of the time server you will be connecting or tweak http response).
Though, the easiest is to get response from some http server.
Related
I created a rest api and I am not very happy with the performance of it. I spent some time to investigate and stumbled across a tool to easily track the performance of my api (www.apiscience.com).
They split the overall response time in 4 categories- connect, resolve, processing and transfer. The resolve part often takes about 150ms while the processing of the call itself only takes about 18ms which results in an average response time of 160ms (the call i tried here is really simple so the average would be higher normally).
My question is how can I improve/minimize the resolve time for my calls?
(side info: my servers are placed in Ireland and I chose Ireland as location for the tests too)
Thanks in advance!
Edit - What do they mean with Resolve Time?
(https://www.apiscience.com/blog/what-do-api-sciences-curl-based-timings-mean/)
API Science’s “Resolve Time” is the equivalent of Ken’s “DNS Lookup.”
DNS stands for Domain Name System. A URL consists of text (and
sometimes numbers); however, the communication addresses that compose
the Internet are formulated as IP (Internet Protocol) addresses, for
example, 208.80.152.2. Before a request can be routed between the
requesting client and the server that will process the request, the IP
address that the URL refers must be looked up. A request is sent to a
DNS resolver by curl, and the resolver returns the correlated IP
address. API Science’s “Resolve Time” is the time in milliseconds that
it took this operation to complete.
As the documentation mentions, the DNS resolution time is the amount of time an API consuming client waits before finding out where to route the actual calls to your API server - the mapping between your server's name and IP address.
Where you host your DNS can be completely independent from both where you host your API service, and where your domain name is registered, and there are multiple choices in the market for DNS hosting service. DNSPerf (of which I have no affiliation) does a comparison of services and is probably a good starting point for further research if you'd like to select a new DNS provider.
I host an SWF clock on my server, the problem is I can't set it to follow the host servers time, instead it follows the clock on my pc, is there a way for me to make the clock follow the server time?
this is the link for the clock
SWF is executed on the client so if the clock calls a method that determines the current time it is gonna be the time on the client. That said, it is of course possible to build a clock which follows the server time. For that, a service on the server needs to provide the current time information and send it to the client.
A related idea is adjusting the time found on the client with that on the server only once and then displaying client time + adjustment, see for instance Get the difference between a server side time and client side time and display it
In the firefox developer tools, under the "Net" panel, resources that are loaded have their load time split into different colors/categories. These are:
DNS Lookup
Connecting
Blocking
Sending
Waiting
Receiving
What do each of these represent, and more specifically, does any of them accurately represent the amount of time that the server is thinking (accessing the database, running algorithms, etc)?
Thanks.
You couldn't accurately determine what the server is doing as such, I'm afraid.
You can discount most of them except Waiting, however, as the rest occur before and after the server handles your request. What it actually does while you wait will be a 'black box'.
There may be some asynchronous operations taking place during Sending and Receiving, so again it's hard to be accurate but you can get a ballpark figure of the time the server is working and the time the request spends travelling back and forth.
EDIT
Rough Definitions:
DNS Lookup: Translating the web address into a destination IP address by using a DNS server
Connecting: Establishing a connection with the web server
Blocking: Previously known as 'queueing', this is explained in more detail here
Sending: Sending your HTTP Request to the server
Waiting: Waiting for a response from the server - this is where it's probably doing all the work
Receiving: Getting the HTTP response back from the server
The firebug wiki also explains these (see the Timeline section).
Blocking Time spent in a browser queue waiting for a network
connection (formerly called Queueing). For SSL connections this includes the SSL Handshake and the OCSP validation step.
DNS Lookup DNS resolution time
Connection Elapsed time required to create a TCP connection
Waiting Waiting for a response from the server
Receiving Time required to read the entire response from the server
(and/or time required to read from cache)
'DOMContentLoaded' (event) Point in time when DOMContentLoaded event was fired (since the beginning of the request, can be negative if the request has been
started after the event)
'load' (event) Point in time when the page load event was fired (since the beginning of the request, can be negative if the request has been started after the event)
There's a pretty good article with time charts and a protocol level explanation of what's happening at each stage here.I found it pretty helpful as they also visually demonstrate the impact of using persistent and parallel connections versus serial connections.
If a regular internet user wishes to contact a TCP service on their computer but without having to go through the hassle of firewall translation I think I'm right in saying that the 'best' way to do this is by having a 3rd party in the middle that will accept connections from both the user's home computer and their travelling computer and act as a proxy.
But how exactly is this achieved? Obviously the travelling computer just contacts the proxy server whenever it wants information, but how is this then relayed back to the home computer? Does the home computer keep a constant connection open with the proxy which allows bidirectional data flow?
If this is the case, how would I go about designing a Ruby/Sinatra server that would keep track of these permanent connections and then forward a travelling computer's queries onwards? (Assume that the home computer's service can make whatever calls would be necessary to establish the link)
Thanks guys!
EDIT
I think I over-generalised, I'm forwarding HTTP requests (or at least, the requests coming from the travelling computer will be HTTP based), so I figured it made sense to use sinatra to capture the requests from the traveller. My problem though is how to keep an open connection from the home computer to the proxy so I can forward the requests immediately.
I know persistent HTTP connections can be done, but that they're a little convoluted, would I be better off having the home computer continually establish a lower level connection with the proxy and push the requests over that?
I think your general methodology will work - relay event messages from one computer to another by having the traveling computer send signals to the proxy and having the home computer request new information from the proxy.
If you want more continuous data flow, you may not want to use sinatra - specifically for receiving the data from the travelling computer. Check out Event Machine - https://github.com/eventmachine/eventmachine/wiki
Is this chat using "long polling" or "http streaming" ?
http://go-mono.com/moonlight/chat.aspx
It's not anything that simple. It uses http://www.mibbit.com/chat, which is a full IRC client written in Javascript and Java. Blog at http://blog.mibbit.com/.
Edit: Here's your answer.
The first part I got working was the communications between browser and server. That’s done using 2 XMLHttpRequests. The first one is simply to send data from browser to server. It utilizes keep-alive, to minimise new connections.
The second XHR is the ‘receive lazy polling’ one. It connects to the server, and the server holds it open until there are messages available, or a timeout expires. This one is also keep-alive, so the next request goes down the same connection.
What you end up with is 2 connections held open to the server, with packets (json in this case), and some http headers from time to time.
To make sure the server would scale, I wrote a custom webserver in java using nio. It handles all of the connections in a single thread and as I say, scales to tens of thousands of connections.
If the client requests a new connection, it sends a request to the webserver, which then connects out, and starts proxying etc. It also runs an ident server in the case of irc connections so that an irc server can identify individual browsers. I looked at existing frameworks etc to do this sort of thing, but I valued learning how it all works, and thought that my use case may be specific enough to be able to optimise more than general frameworks can.