Our flex app talks back to its originating server over a TCP-socket connection. This requires an allowance from the server in question and thus we've set up a socket policy server at the host (source code at pastie.org/791060).
This has worked fine on many permutations of Firefox, Safari, Windows and Mac OS X, but then yesterday we discovered problems with IE 7 on Windows XP. In about 50% of the cases a SecurityErrorEvent is raised upon socket.connect. This despite calling Security.loadPolicyFile("xmlsocket://:843") before connecting, and the observation of the socket policy server transmitting the socket policy data to the client (checked with tcpdump). The error can often be undone by reloading the flash app in question, while restarting IE triggers its return.
Why do we see this intermittent errors, and what can we do about them?
Regards,
Ville Jutvik
Jutvik Solutions
I've pinned the issue down to a bad socket policy server implementation. It seems like it hanged up too early in the TCP conversation with the flash client (didn't wait for the string), causing the connection errors under some circumstances, IE 7 on Windows XP notably. I didn't know that it was so easy to create havoc on the TCP level from the user level...
Heath: Thank you for your time. I will keep your hypothesis of the firewall acting up in my mind because I will surely encounter it later on as our testing progresses.
/Ville
Related
Background
In a version of Safari that supports HTTP/2 (i.e. v9+) running on macOS “El Capitan” v10.11 or newer, when accessing a webpage served from IIS10 via HTTP/2 (e.g. Windows Server 2016 / Windows 10), if the page contains a "Response.Flush" then it will not load. It simply hangs with a white screen. Web server CPU usage also spikes during these occurrences.
This thread suggests that when Response.Flush is used, IIS switches protocol from HTTP/2 back to HTTP/1.1. Safari cannot handle this, whilst all other browsers seemingly can.
Demos from the link above:
Working - http://limoeventplanner.com/safari-test.asp
Not working - https://limoeventplanner.com/safari-test.asp
I appreciate that the solution to this problem may lie elsewhere (I currently have a bug open with webkit), so I will try to make my questions focused...
TL;DR
Does using Response.Flush still make sense in a HTTP/2 environment?
Is the "downgrade" to HTTP/1.1 by IIS the expected behaviour in this scenario? If so, why?
I running an Ubuntu VM via Vagrant on a Windows 10 host. On the Vagrant machine I am running a fairly standard PHP/nginx app.
Whenever I try to access the web app, it takes forever to load. Chrome network inspector shows this:
Chrome network timeline
This huge latency is completely gone on subsequent requests, but whenever I pop back into the browser and try again after a while, it crops up yet again.
I am using NFS.
I have disabled firewalls on both guest and host machines.
I increased keepalive_timeout in nginx which helped hide the problem, as it increased the time window for latency-free subsequent requests.
This latency occurs even when accessing static files, so I don't think it's a PHP-FPM/MySQL problem.
I successfully figured out what my problem was!
After looking at my Windows hosts file, it looked like my vagrant-hostmanager plugin had not been properly clearing out older IP entries (i.e. I had three seperate IP entries for myapp.dev even though only one IP was active). Probably because I'd forgotten to properly vagrant halt before shutting down my PC a few times.
Windows was clearly spending ages trying to resolve the two older entries before successfully resolving the 'real' one.
It's weird: you'd think this problem would cause the latency to show up in the DNS Lookup portion of the Chrome network timeline, rather than Initial connection, but oh well!
We are trying to optimize our ASP.NET MVC app and get a big time difference between our server side logs and client side delay.
When refresh the page in Chrome in Timeline it shows 4.47s:
As I understand from the picture, the time for server side code execution should be 3.34s, but in our server logs we have the following:
Begin Request 15:41:52.421
End Request 15:41:53.218
Pre Send Request Headers 15:41:53.218
Pre Send Request Content 15:41:53.218
So, according to server side logs code execution took only 797ms in total.
It does not happen all the time and very often the Chrome timeline shows times very close to server logs. But sometimes we have this couple of seconds delay.
Where could this delay come from?
There is lot of stuff that can affect the time sporadically to such an extent, even though addition of almost three seconds is sort of excessive for this scenario. Since you don't mention much about how is your network set up, what operating system u use etc,
I'll try to sum up a list of what comes to my mind when dealing with this sort of a delay, sorted by probability.
The main problem here is the Waiting part of the total time there you should concentrate your detective talent.
Please note that the answer is very general since the question says virtually nothing about configuration of the server, client computer or the network (if any) between them. Since you say the delay is not present all the time, there are one or more moving targets you need to aim at.
Antivirus
If you have an internet shield or similarly named component, it is not uncommon that the antivirus can seemingly randomly delay some connections while leaving other virtually untouched. For the browser this is transparent (it's just a delay, whatever may have caused it), hence the Waiting.
Network issue
Especially if you are connected through a wireless network or poorly configured wired network, a few seconds delay may occur even though the label on the network device says TurboSpeedTM.
Server side issue
Server may be overloaded with previous requests in a manner not covered by your in-application timer, since there are many steps the server performs before and after your script is executed.
Client OS issue
Just like the antivirus, the OS can delay your packets virtually randomly for various reasons.
When hunting down such issue, I would recommend trying to perform the query on the server itself and compare resulting times, try as may combinations of network setup and operation systems as possible, prefer well planned network environments to those with many unknown or external factors (read wireless) and make use of some packet sniffing software (like wireshark) to check whether the browser doesn't lie. And that would be just the start of it :)
I am working with a Meteor mobile application with Cordova and PhoneGap.
My app is working fine over a Wi-Fi connection. But whenever I use it on mobile networks, 2G or 3G, it stops working. Meteor.status() returns disconnected all time on mobile cellular networks.
What is the solution for this problem?
This could occur if you have a bad connection. The Meteor in the device's browser can't really tell what network it's on. It just uses whatever it gets.
As soon as it can get a connection back it should reconnect. Keep in mind with 2G (EDGE/GPRS) connections you might have to wait a bit longer for the HTML/JavaScript to connect to the DDP server as all the client HTML/JavaScript data needs to be downloaded first. This can take quite a while.
The other thing is to ensure your (3G) connection isn't over some kind of proxy, especially if you're hosting the application yourself on an unusual port number (websockets usually fall back to long polling, though).
If you sign up for the RIM developer alliance program, you have the special BIS-B connection type available to your Blackberry applications.
Is this connection type more available, stable, and reliable than the other methods? We're connecting to web APIs, if that makes any difference.
Getting the other methods (Direct TCP through APN gateways, WAP, WAP2, Unite) to work properly in all cases is a bear so I'm hoping BIS-B is a good way to solve this issue for our app and help some customers that have a financial incentive not to connect through WAP connections.
BIS connections have worked pretty well for us. However, some customers (especially the once using Enterprise Servers) have BIS connections disabled and force all traffic through their MDS. So I'd always make sure your application has more then one way to connect to the web. But be careful - when your application tries using MDS connections as well as BIS connections, you might run into a probmel known as 'split-pipe', which is extremly hard to debug.
For security reasons some devices block applications to do both internal and external connections (MDS and BIS), they do this silently (so you're connections just fail) and it's permant as long as the application is on the device. There is a policiy on the BES to activate/deactive this and I havn't seen it always happening, sometimes BIS/MDS works just fine, but keep that in mind.