Notice how I say not connecting rather than just being slow.
This has been very difficult to reproduce, I am yet to get it to happen consistently and even went to far as to move the application on to a fresh machine thinking it was hardware related but alas, new machine - same issue.
Some captures with Fiddler seems to indicate that the connection is never completed.
Any suggestions on further investigative measures?
Apologies in advance for the vagueness of the question, I am just at a loss.
Can you instrument it from the IIS side? Request tracing could tell you if something is taking so long that the request times out before it returns . . .
Are you attempting to connect via HTTPS? I've had issues in the past when trying to run on my local box and I initiate a HTTPS connection which isn't supported by cassini. When a HTTPS connection fails it's not always obvious why.
Related
I have a server application which runs on a Linux machine. I can connect this application from Windows/Linux machines and can send/recieve data. After a few hours, something occurs and I get following error on the client side.
On Windows: An existing connection was forcibly closed by the remote host
On Linux: Connection timed out
I have made a search on the web and found some posts which suggest to increase/decrease OS's keep alive time. However, it didin't work for me.
Can I found a soultion to this problem or should I simply try to reconnect to the server when the connection is forcibly closed?
EDIT: I have tracked the situation. I sent a data to the remote node and sent another data after waiting 5 hours. Sending side sent the first data, but whet the sender sent the second data it didn't response. TCP/IP stack of the sender repeated this 5 times by incrementing the times between retries. Finally, sender reset the connection. I can't be sure why this is happening (Maybe because of a firewall or NAT - see Section 2.4) but I applied two different approach to solve this problem:
Use TCP/IP keep alive using setsockopt (Section 4.2)
Make an application level keep alive. This is more reliable since the first approach is OS related.
It depends on what your application is supposed to do. A little more information and perhaps the code you use for listening and handling connections could be of help.
Regardless, technically a longer keep alive time, should prevent the OS from cutting you off. So perhaps it is something else causing the trouble.
Such a thing could be router malfunction or traffic causing your keep-alive packet to get lost.
If you aren't already testing it on a LAN (without heavy trafic) I suggest doing so.
It might also be due to how your socket is handled (which I can't determine from your question)
This article might help.
Non blocking socket with timeout
I'm not used to how connections are handled on Linux, but I expect the OS won't cut off a connection unnecessary.
You can re-establish connection as a recovery, but you need to take into account that not all disconnects are gentle, and therefore you could end up making recovery on a connection you actually wish to be closed.
Since it is TCP, it will do its best to make a gentle disconnect, but you can send a custom message telling the server or client not to re-establish the connection right before disconnecting. That way you be absolutely sure, despite that it should be unnecessary to do so.
i have hosted my project on azure server of Asp.net MVC, and i have used azure sql, its work fine, but number of times while performing any operation , i.e. when fire calls from controller it gives error like,
"An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full Ip"
and after few minutes its starts to work fine,
can anyone tell me why this error is throwing or is there any solution for this??
This is most probably client side issue (ASP.Net app side). This could happen if you do A LOT of simultaneous socket connections or do not dispose connections properly. Please double check your application and make sure that:
You properly close all database connections (use using() or call Dispose()).
You properly close any other socket connection (if any).
If your code is fine, you can try to use Transient Fault Handling App Block. It won't solve the issue itself but could help your app to workaround it.
I wrote a multi-tier application suite in Delphi XE, using DataSnap (VCL application).
This will be used internally, in my company, mostly to replace the outdated fax communication.
Everything works fine, but I came across an unpleasant situation: The server machine is behind a router, so it has an internal network IP. I forwarded (in the router) all incoming connections on port 211(DataSnap default) to the server's internal IP and about 8 times out of ten all the clients connect to the server without any problems.
The problem is that for the rest 2 times I get all sort of connection errors (mostly connection timed out). When it does this I have to close and reopen either the server application either (some of) the clients, and then it works.
Right now I'm still in the design phase, so it's only a bother, but when I do release it I don't want either to tell everyone NOT to EVER close the application (once it works, it works, no more problems), either close and reopen the applications each time there is a connection problem.
How can I eliminate this problem?
I had (only) a look at NetCat and SoCat, but (to me) it seems overkill for this situation. Is there another way to solve this?
The solution was switching off router's internal firewall.
So I have been looking every where, and so far i haven't been able to find anything that allows me to ssh from an iPhone app, and have finally resorted to posting a new pos.
So I am trying to make an app to manage servers and part of the tasks that I need to be able to do it to be able to some how remotely connect over the internet to a server with either an ip address or a DNS name.
The connection to the server does not necessarily need to be a SSH connection, it could be a telnet although because of the security issues i would prefer SSH (if it is a lot less code I would accept telnet), but on the other hand it could be some other type of connection.
The application just needs to be able to run a script on the server end and if a SSH or telnet I would not need any help but if some other type of connection i may need a bit of help. Also the server on the other end is intended to be linux server (either ubuntu or gentoo, but not sure which yet but all i can say is will almost certainly be a linux server operating system).
I have already looked at the libssh/2 and would welcome any other similar demos as have not been able to work out how get the frameworks to work as well as licensing issues with using the frameworks in it.
PS. I am relatively new to programming and although i have some basic knowledge of coding some type of tutorial or sample code would be greatly appreciated.
Many Thanks For Any Help
Thomas
SSH is a hugely complicated beast. As long as you only need to execute one command without interactivity, it sounds like you could achieve the same thing by running a web server on the server and posting the commands via HTTP from the device. You can use SSL to achieve security. You'll need a mechanism that allows you to authenticate the device (you'd need something with ssh, too). And you'll have to have something in the web server on the server that figures out and runs the desired script. But all that is still hugely easier than dealing with libssh.
The logs don't show anything different, and the computer is four times faster than the last one. Anyone know any common reasons why making a request to localhost would take a very long time?
I am using Mongrel.
Hard to give a solution based on the little information you give, so try to narrow it down. I would say that these three causes seem the most likely:
the database is slow. You can check this if your queries take a long time (check the logs). Perhaps you are using a slow connector (i.e. the default Ruby MySQL library), or your indexes haven't made it to your new machine.
Mongrel is slow. Check by starting it with Webrick and see if that's any better
your computer is slow. Perhaps it's running something else that's taking up CPU or memory. See your performance monitor (application to use for this differs per OS).
Could be a conflict between IPv4 and IPv6. If you're running Apache you have to take special steps to make it work nicely with IPv6 (my information here might be out of date.) I've found that an IPv6-enabled client would try to talk IPv6 to the server, and Apache would not receive the request. After it timed out the client would retry on IPv4.