I want to produce a request time on internet of a machine, its for testing purpose for an application what happens when internet suddenly time outs.
Updated
system is windows server 2008, i want to do it manually just to check if the winform application keeps dispatching emails if there is a sudden ping break
You can simulate it by (a) ignoring the reply, (b) filtering out the reply packet in firewall. Depends on your system.
Could your developer not just throw a ping exception in their code? obviously you haven't mentioned the programming language as #Tim S commented, but in C# there is a PingException class - MSDN link .
Related
I have a application I wrote that uses a serial port (hand scanner connected to it) and I need to detect somehow that another user switched so I can close that port and when the new user logs on to the application it wont get 'port in use' error. Any suggestions? My program is in VB.Net but open to any suggestions.
This is a common issue unfortunately.
I find the best thing to do is create a Windows Service to handle all of the comms so that it works independently of any user being logged in. You can use a WCF/Web Service to get data out of the Windows Service.
I hope this helps.
(I would have posted this as a comment instead of an answer if I could)
This question is related to a connection reset question I asked recently. I am also pursuing the info in this SO article and this SO article. What I want to know is the best way to track down the cause of an IIS Thread Pool crash. I am also pursuing this problem with our vendor. Here are the details.
I have an IIS application. It uses a very simple ASP page, modeled on a sample supplied by our vendor, when we purchased our first COM toolkit quite a few years ago. This application runs on IIS on Windows Server 2003. The application is a separate web service, not a virtual root, and it's at a different port number than 80. In other words, we're not using another NIC or virtual IP address. The site has little traffic, but was configured to have a DMZ. The whole configuration looks a bit funky to me.
Address verification requests are sent to the IIS application from browser-less applications that use http protocol. Street number, street name, city, and state are sent with a few other pieces of identification, and a response is sent back. One of the applications is written in C; the other is written in Clojure.
Sending "single-shot" requests to the newly built IIS application works just fine from both applications. Sending a lot of requests, and it's been hard to pin down whether that's over 25 or some other number, causes the IIS thread pool to crash. That's more or less what the error logs say.
This application has run without incident for years on a W2K/IIS server. The ASP page talks to an address verification engine by means of a COM toolkit that we purchased from the vendor. We had to upgrade to a new server (and 2012 COM toolkit) only because the newest COM toolkit would not install on W2K, and the new COM toolkit contained support for the new USPS address verification regulations. We'll validate fewer addresses without the new toolkit, and the only way you can barcode addresses and get that discount is to validate addresses. (When you send out 29,000 motor vehicle excise bills, the discount helps.)
What is the best way to track down this problem, so I can find the culprit? I'm looking for links to good information as much as answers. I am sorry to be vague; I know the rules of SO, and endeavor to provide as much detail as possible. I can re-edit this post and provide log entries, if someone wants to see those. The bottom line is my Clojure client (handles the batch requests) starts getting resets, and crashes, when the IIS thread pool crashes.
Epilogue:
We believe the rapid opening and closing of the COM object is the issue, and our writing the ASP page this way was sanctioned by our vendor. To get around this problem and the fact we also needed to install MS Access for additional address verification functions, we wound up writing an ActiveState Perl program to solve multiple needs.
First, we have purchased an ActiveState product that will the our Perl program run as a service. The service will start with parameters and a port number that allow the http-based requests to be sent, just like the were before. In this case the COM object will be opened once when the Perl program starts, and close when the Perl program exits.
The other functions provided by the Perl program are not germane to this post, but the writing of this Perl program obviates the need for IIS and MS Access, which were required with the old configuration.
So, if you want to take something from this post, it would be open a COM object on opening of a program and close on program close, at least for W2K Server 2003 and higher.
We had an issue at work with respect to application slowness. We did an application pool memory dump and then analysed the dump.
http://support.microsoft.com/kb/919790
I've got a number of ASP.Net websites (.Net v3.5) running on a server with a SQL 2000 database backend. For several months, I've been receiving seemingly random InvalidOperationExceptions with the message "Internal connection fatal error". Sometimes there's a few days in between, while other times there are multiple errors per day.
The exception is not limited to one site in particular, though they share business and data access assemblies. The error seems to always be thrown from SqlClient.TdsParser.Run(). It sometimes is thrown from old-school direct SqlCommand.Execute() calls, while other times it is thrown from Linq2Sql code.
I've been assured by the network guys that there are no errors or packets lost on their end. Has anyone else experienced this? Could it be a driver problem? We have been unable as of yet to pinpoint a specific trigger for this exception.
We're running II6 on Windows Server 2003.
After a few months of ignoring this issue, it started to reach a critical mass as traffic gradually increased. Under heavy load, including some crawlers, things got crazy and these errors poured in nonstop.
Through trial and error, we eventually tracked down a handful of SqlCommand or LINQ queries whose SqlConnection wasn't closed immediately after use. Instead, through some sloppy programming originating from a misunderstanding of LINQ connections, the DataContext objects were disposed (and connections closed) only at the end of a request rather than immediately.
Once we refactored these methods to immediately close the connection with a C# "using" block (freeing up that pool for the next request), we received no more errors. While we still don't know the underlying reason that a connection pool would get so mixed up, we were able to cease all errors of this type. This problem was resolved in conjunction with another similar error I posted, found here: Why is my SqlCommand returning a string when it should be an int?
Sounds like the database connection is getting dropped or timing out.
We recently had similar issues moving to IIS 6 from IIS 5 connecting to SQL 2000. Our issue was solved by increasing number of ephemeral ports available.
Look at the usage of the ephemeral ports by the IIS server. The default max no. of ports available is normally 4000. You might want to consider increasing this if the sites on your server are particularly busy or your application is making a lot of database calls.
You can monitor these first to see if going over max limit.
Search Microsoft Knowledge base for "MaxUserPort" and "TcpTimedWaitDelay" and make necessary registry changes. Make sure you back up registry or snapshot server before making the changes. Will need to reboot for changes to take effect.
You should double check your database and recordset connection are being closed after use. Not closing will use up this port range unnecessarily.
Check the efficiency of your stored procedures anyway as they might be taking longer than they need too.
"If you rapidly open and close 4000 sockets in less than four minutes, you will reach the default maximum setting for client anonymous ports, and new socket connection attempts fail until the existing set of TIME_WAIT sockets times out." - from http://support.microsoft.com/kb/328476
Check your server's LOG folder (\program files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG or similar) for files named SqlDump*.mdmp and SqlDump*.txt. If you do find any you'll have to take it to Product Support.
I was creating a new EF Core project and was trying to create the database to an external Linux server instead of a Windows Server or local one. After hours of searching I found out that I am using MySQL instead of the Microsoft SQL server.
I found it weird that everyone was using 1433 instead of the usual 3306. So to fix my 'Internal connection fatal error' I had to set up a docker instance of SQL Server bound to its default port of 1433.
It literally was that simple. In the docker repo look for "microsoft-mssql-server" and run the image as described neatly in the description below. Everything works now and I am able to push my database from my EF Core project to an external server.
A bit of history: We have an application, which was originally written many years ago (1998 is the first date in PVCS but the app is about 5 years older than that as it originally was a DOS program). This application communicates with a piece of hardware via serial. When we got to Windows XP we started receiving reports of the app dying after a short time of running. It seems that the serial comms just 'died' and the app was left in a stuck state. The only way to recover from this situation was to restart the application.
The only information I can find regarding this problem was apparently the Windows Message system would miss that information was received, the buffer would fill and the system would get stuck. This snippet of information was left in a old word document, but there's no evidence to back this up. It also mentions that this is only prevalent at high baud rates (115200+).
The solution was to provide customers with USB->Serial converters along with the hardware.
Today: We are working on a new version of the hardware that will run across a network as well as serial ports. So to allow me to work on the network code, minus the actual hardware we are using a VSCOM NetCom113 device. It also installs a virtual comm port on the users (ie: mine) machine.
Now I have got the network code integrated with the app, it appears that the NetCom device exhibits the same behaviour as a physical commport. This is undesirable as I need the app to run longer than ~30 seconds.
Google turns up zero problems that we experience.
I was wondering:
Has anyone experienced this before? If so what did you do to fix/workaround the problem?
Does anyone have any suggestions as to whether the original author of the document is correct and what I can do to test the theory?
Unfortunately I can't post code as the serial code is tightly couple with the rest of the system, though if you have questions regarding it I can answer questions about it.
Updates:
The code is written using Win32 Comm routines - so I am using CreateFile, ReadFile. There's also judicious calls to GetOverlappedResult.
It's not hanging per se, it's just that the comms stops. You can access the menus, click the buttons, but nothing can interact with the connected hardware. Using realterm you can see that no data is coming in or going out.
I think the reference to the windows message is that the problem is internal to windows. Data has arrived but the kernal has missed it and thus not told the rest of the system about it.
Flow control is not used.
Writing a 'simple' test is difficult due the the fact that the code is tightly coupled and the underlying protocol is quite complex and would require a lot of work.
Are you using DOS-style serial code, or the Win32 CreateFile approach?
If the former, be very suspicious: if at all possible I'd convert to the latter.
If the latter, do you know on what kind of system call it's hanging? Are you in a blocking read call? or an overlapped I/O call? or waiting on an event? (I'm not sure I have enough experience to help, but those are the kinds of questions that come to mind)
You might also check into the queue size, which you can set with the SetupComm function.
I don't buy the "Windows Message system" stuff -- it sounds fishy; you can write good Win32 serial i/o code that never uses Windows messages.
edit: does your Overlapped I/O use events? I seem to remember something about auto-reset events occasionally missing their trigger... check your overlapped I/O calls very carefully to see whether you're handling the possible outcomes properly. Perhaps there's a way to make your code more robust by automatically cancelling the overlapped i/o and restarting another read. (I assume the problem is in the read half, not the write half?)
edit 2: A suggestion: assuming the win32 side has missed a byte or packet, and your devices are in deadlock because they're both expecting each other to respond to something, can you tweak the other side of the serial I/O to regularly send some type of "ping" packet with an incrementing counter? (and log the ping packets on the PC side; that way you can see whether you've missed any)
Are you sure you have your flow control set up correctly? DTR, RTS, etc...
-Adam
i have written apps that use usb / bluetooth serial ports and have never had an issue. with bluetooth i have seen bit rates (sustained) of 800,000 bps for long periods of time. most people don't properly implement the port.
My serial port
Not sure if this is a possibility for you, but if you could re-write the code using C#.NET you'd have access to the SerialPort class there. It might remedy your problem. I know a lot of legacy code based around the Win32 API for hardware I/O ports tended to fail in XP due to timing (had a small bit of experience with MIDI).
In addition, I don't know if you can use the Win32 method of Serial Port access in Vista, so that might shut out future MS OSes from being able to use your code.
I have a website running a basic ASP.NET application that is mostly used from a single location, which is my client's office. The server is at a high-class datacenter.
Whenever I've been testing or using my application from outside their office I have consistently good connections but from their office the connection seems inconsistent. Sometimes requests just don't seem to make it to the server from the browser. I'm not familiar with the network hardware in the office, but they do have a T1 connection which should always be on.
I've tried ping and tracert and everything looks normal. When running Firebug during a failed request the request shows up in the log, then just sits there without showing it is sending any data, eventually it times out.
My question is, what tools can I use to diagnose this connection problem and start to narrow it down to a specific cause so I can fix it? Its an intermittent problem so a long running tool would probably make more sense, if there is any available.
Thanks for any help.
All of your standard ping and traceroute tools are probably your best bet. I'm not understanding though, where is the site located?
If you open command prompt, run ping -t aspwebsiteurl.domain <- will show if there is packet loss.
From command prompt again, tracert aspwebsiteurl.domain <- will show you what route the packet is taking to get the site. May also show you if there is one particular hop that is giving you the hickup.
Is there a proxy between the office and the datacenter that could be causing issues?
Also you could try Wireshark to try to debug the problem in more detail.
Speed Test - Internet Network Connection Speed may be of some help with some links to test out the connection at the client's office to see how well it works.
Another question is how far away is the client and the datacenter? If one is in New York and the other in Los Angeles then the distance apart may be a factor. Also, have you examined any possible DNS issues?