I have Server and Client scripts in C# programming language. When I create server on my computer and from another computer I'm trying to connect to the server it says:
an existing connection was forcibly closed by the remote host
It's happening when I change the IP of the server to 0.0.0.0 (IPAdress.Any)
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
It' happening when I change the IP of the server to IPv4 which is 10.0.0.6 (On the ipconfig - IPv4).
Also I turned off the Firewall, And I opened port (11000) on website of the router.
I put in the client the public IP address of the server (which is on whatismyip.com).
The program works perfectly when it is on the local network (I mean when the both computers have the same network).
Scripts:
Server code : http://pastebin.com/awsrkjk4
Client code : http://pastebin.com/2Xrm8YnA
Does anyone know how to solve it?
First of all, check to make sure your server is actively listening on the TCP port you expect. If it is a Windows machine, from the command line try:
netstat -ano | findstr ***LISTENINGPORT***
In your case I'm guessing you should be listening on 11000.
If so, on the client side, let me know exactly where your code is breaking. I'm assuming for now it's this:
sender.Connect(new IPEndPoint(IPAddress.Parse(ip), 11000));
.. and also run a WireShark capture on the client machine.
There are plenty of quick start-up guides - basically this will allow you to see the request your Client is making across the network, & see if a connection (if any) is being established on the server.
If you ARE making a connection, then it is just being closed for another reason, then you have a code issue. If NOT, then you have a network/configuration issue. This should help you make progress.
I'm trying to configure IIS 7.5 so that it can serve large (400mb) files via HTTP. The client is a C# client using WebClient.DownloadFile() (basically wrapping an HTTP GET request).
However when downloading, I occasionally get the error from the client:
An established connection was aborted by the software in your host machine
Anything I can do in either the client or IIS to prevent this error?
After much digging around, it looks like a dodgy internet connection on my side. All clients on my site disconnect at the same time, but clients on another site stay connected. Unfortunately the internet router that I have here doesnt have any connectivity logs (its a top-of-the-range linksys.. go figure) so it wasnt easy to see what the problem was.
I have a simple piece of code in a .NET console application that tries to open an SQL connection to a server:
using (SqlConnection connection = new SqlConnection("<my connection string>"))
{
connection.Open();
}
It works perfectly fine on my Windows 7 machine, but on my other machine running Windows XP x64 the call to Open() hangs indefinitely.
Any ideas why this is happening or how I can diagnose the cause? I am running the program from an administrator account on both computers.
EDIT: Ok, it seems to be a firewall issue. I've connected my Windows 7 machine to the same internet connection as the Windows XP machine and now it hangs too... what ports do I need to open to let SQL traffic through, and how do I go about opening them?
EDIT: In case anyone's interested, my network admin was blocking outgoing traffic to port 1433 out of fear of the Slammer worm ...
Since I can ping and attempt to connect to database2.ehost-services.com (though I received a Login failed), let's try to simplify your connection string:
Data Source=database2.ehost-services.com;Initial Catalog=myDatabaseName;User ID=myUser;Password=myP#ssword;
EDIT
To answer your question regarding why your connection string did not time out, MSDN describes the pooling attribute of the connection string as follows:
When the value of this key is set to
true, any newly created connection
will be added to the pool when closed
by the application. In a next attempt
to open the same connection, that
connection will be drawn from the
pool.
Connections are considered the same if
they have the same connection string.
Different connections have different
connection strings.
The value of this key can be "true",
"false", "yes", or "no".
So I'm thinking perhaps your connection instance wasn't actually pooled yet to time out.
EDIT
From your error message it looks like you're using NAMED PIPES instead of TCP/IP. Maybe this can help you out (use SQL Server Configuration Manager to select your protocol). Check under [SQL Native Client 9.0/10.0 Configuration] and you should see a list of protocols. Make sure TCP/IP is listed with an order before Named Pipes and is also ENABLED. For example, my order of 1 - 3 is Shared Memory, TCP/IP, Named Pipes, and VIA is disabled.
EDIT
Try creating an Alias with TCP/IP protocal selected and connecting to your alias? You can do this also using SQL Server Configuration Manager.
EDIT
As the OP has resolved the issue, I did make the comment on someone else's answer:
A security policy that blocks outgoing
would have to be explicitly created
and SOB, that's what it was - network admin blocked outgoing traffic on port 1433. Glad you figured it out!
Are you sure your database server is accessible from both of your PCs? Have you tried connecting to it from the problematic system using another tool?
And how long have you let it run?
I have run into a situation with a C# application installed at two sites where the initial connection to SQL Server is extremely slow. I wrote a test application to verify where the slowdown occurs and it is on the first SQLConnection.Open statement. It was taking about 41 seconds to establish a connection to the server via named pipes. We thought it might be a DNS issue but its just as slow using a TCP/IP connection. After the initial connection is made the connection is pooled and the application responds normally. Both the workstation and the server are decent machines running Windows 7 Pro, Core 2 Duo 3.16 Ghz with 4 gig of Ram. I did find the following article on a microsoft forum:
http://social.msdn.microsoft.com/Forums/en/windowscompatibility/thread/f295994c-5812-4e46-8ac9-f05471d4dd54
Turning off the LLMNR protocol did cut the initial connection time in about half to 21 seconds. However, this is still a long time to get an initial connection to SQL Server. The only things slightly different from our norm is that DNS in this case is done thru a router and not an actual server. This has occurred at only two places so far, others run with no issues. Any help would be appreciated.
Thank You,
Dennis
In front of the server on the connection string, add np:
This becomes Server=np:server\instance and forces the Named Pipes instead of the default of TCP.
I could of probably changed the priority to use Named Pipes before TCP... but I did not want to mess with that on the server.
I saw similar problem but not sure it's the same as yours. In my case, it's not just the C# program being slow to make the SQL connection. It's any tools connecting to SQL server also experiencing the slowness. Also, once the initial connection made to the SQL server, any subsequent connections are fine for a period of time.
The reason was that SQL server was using a number of managed assemblies. It's trying to verify the cerfiticates assigned to the assemblies. It's connecting the crl.microsoft.com. My SQL server didn't have the internet connection. So, it waits for the timeout.
The solution was to make my SQL server to have internet access or disable the CRL checking. You can go to the SQL server machine. Select Tools > Internet Options > Advanced. Check if the publisher's certificate revocation under the secuity node is checked or not. If it's checked, uncheck it.
I tried specifying the connection string with integrated security = false (meaning the user id and password are in the connection string) and encrypt = false (just be be 100% sure SSL encryption is not being used). These specifications did not seem to help and I could not get a connection explicitly using the TCP/IP network library (NetworkLibrary = "dbmssocn"). This could have to do with the server firewall and the port not being open. I switched back to named pipes and put the named pipe network library specification in the connection string this time (NetworkLibrary = "dbnmpntw"). After this change, the connection was made instantaneously.
Establishing an integrated security connection to SQL Server using the IP address (instead of a host name), will prevent Kerberos authentication being used. In this scenario check the connection between the SQL Server and the domain controller.
If you connect using the host name (not the IP Address) Kerbos is in play, in this case you need to check the client machine's connection to the domain controller.
We had the same problem, and it turned out that our remotely-hosted Active Directory server was to blame.
We created a site-local Active Directory server to replicate the remotely hosted AD master and then all of our slow SQL Server integrated security authentication performance issues went away.
I hope that helps.
Yeah when you're using integrated security, Active Directory can be the one to blame, also the overall network since it all depends on it. Another thing I could think of is the edition of SQL Server you're using.
Also, when SQL Server is not being used by long periods of time, it behaves similar to IIS, putting the worker process to sleep, so when you contact the server again, depending on the machine (we can see that these have desktop machines configurations), it will take some time while the worker process gets back to life and is ready to work.
You did check the obvious I take it? That UDP port 1434 is open on the firewall and the browser service is running .... would take about 40 sec to authenticate otherwise.
there are other methods of creating connections to SQL databases. Try finding a tutorial which uses the
sqlconnection myCon = new sqlconnection(details);
myCon.Open()
instead of creating an object to instance the connection.
I don't have a concrete answer but have you tried running SQL Profiler to see what is going on from SQL's point of view?
Also have you tried connecting to SQL using the same credentials as your connection?
On the other hand it may all be much lower level but I always do the easy to check stuff first.
Good Luck.
It sounds like either name resolution is taking a while or authentication is taking a while. After the initial resolution or authentication's occured, then details of endpoints are cached by the server so it doesn't need to perform the lookups again until caches expire.
As an experiment, try ping'ing the server from the client box -- if this takes a long time to resolve the hostname, then you've found the culprit: hostname lookups (DNS or NBNS). Another alternative is to use the host IP address rather than name. So if you've got a SQL Server named instance of bob on server sql2005-01, and this server has an IP of 192.168.200.12, then try connecting to 192.168.200.12\bob instead of sql2005-01\bob.
Authentication's more awkward to resolve, but you might be able to test it with runas on the SQL server box (e.g., runas /user:domain\user cmd to see if you can open up a command prompt as the user you're attempting to authenticate as.
It could easily be a problem with either the connection or the authentication, it is normal that the first connection takes longer as ADO.NET has connection pool to avoid that long connection time.
There are many factors that can influence the speed:
- TCP/IP configuration
- Routers on the server-side
- etc.
Still if you are facing the issue, please see blow resolution:
Root Cause
The issue which we were seeing on Win7 VDIs could be due to the Network hardware device connected with the machine. If TCP/IP scaling is not supported by the network device then the performance will be slow.
Solution
Disable auto tuning level of the TCP. Please follow below steps:
1) Open command Prompt with admin right (Run as Admin)
2) Type “netsh interface tcp set global autotuninglevel=disabled”
3) After running above command restart the machine.
For other information on this command, visit link “http://support.microsoft.com/kb/935400”
I had the same problem. After vigorous research on google and stackoverflow, i changed the client computer's hosts file (In windows,located at C:\Windows\System32\drivers\etc).I entered my host's ip address and server name in this file and Viola!. Things became superfast!
Like everybody in stackoverflow said, it was the computer looking up the servername's address in the DNS service and getting a timeout.
The steps i did follows.Give it a try if nothing else works.
HOW TO ADD AN ENTRY IN HOSTS FILE
1.Open the command prompt and ping your server,where the remote database is located. To do this enter the following command:
ping servername
Here my remote computer name was Juno. So i should ping like this.
ping Juno
This command will ping my server and returns ip address like this.
Pinging Juno [192.168.0.3] with 32 bytes of data:
As you can see the ip address of the server is between the brackets.
Copy the ip address.
2.Now Open the Hosts file with elevated Notepad(Run as administrator).
At the end of the hosts file,there will be some lines like these:
#localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
At the very bottom (here,after the localhost),type # and enter the ip address of the server we just obtained preceeded by server name.
So, the hosts file should look like this.
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
# 169.254.63.1 Juno
Now save the hosts file and restart the Client PC. (For me,it worked instantly without restart.)
Annd there you go!
For more info about editing your hosts file,click here
In my case the answer was:
Try everything with no result.
Remote Desktop to the (non-prod) SQL Server to double check settings.
Close down Visual Studio you left running after doing a quick SSIS job.
Go somewhere quiet and kick yourself.
Open Start -> Microsoft SQL Server 20XX ->SQL Server Configuration Manager
SQL Native Client 11.0 Configuration (32bit) -> Client Protocols -> (Ensure all items are marked as "Enabled")
SQL Server Network Configuration -> Protocols for MSSQLSERVER -> (Ensure only Shared Memory item is marked as "Enabled", others should be "Disabled")
SQL Native Client 11.0 Configuration -> Client Protocols -> (Ensure all items are marked as "Enabled")
Reboot computer
Ensure SQL Services are running and attempt to connect to local MSSQL
Connection should be much more rapid
I want to know how I can send or recieve data over internet to/from a computer in subnet
(this is specially in context to PPP users bcoz getting static IP is not so much in practice).
I actually want to create an application which can transfer file between 2 specific computer in WAN.
so what are things I need to know about to do the same..(ex. PRESENT IP or MAC ADDRESS etc..)
PROGRAMATICAL EXPLANATION ALTHOUGH PREFFERED,BUT IS NOT NECCESARY...
FTP?
There is a vast torrent of useful results in google, I seriously suggest to google before you ask here.
For instance, have a look at the top result: http://www.devarticles.com/c/a/C-Sharp/Network-Programming-in-C-sharp/
Apart from that, FTP, as suggested by Colin, may be what you're looking for. If you're new to using FTP in C# have a look at http://www.google.com/search?q=c%23+ftp
Put the information on a public IP server, so both computers keep polling if there is new data and send / download that data as needed. A single text file can hold necessary flags such as paths and other info you need.
server just need to be a web server, which means IIS or similar should be installed.
I'm thinking part of your question has to do with one of the computers not having a static IP address. If the two computers, A & B, don't know each others IP address, then an alternative is to use a server. Either A can store the information on the server to be picked up by B, or A can register his current IP address on the server for B to lookup and then connect to A, assuming firewalls don't interfere. Another scheme is that A and B can simultaneously connect to the server, and the server can relay data between the two.
Of course, all of this communication would be done using techniques such as those suggested by mafutrct and Colin.
This question sounds to me like the difficulties of NAT Traversal and trying to establish peer-to-peer connectivity over the Internet. I stumbled on this question researching the best way to set up Internet connectivity to a device that is sitting behind a firewall. I am assuming that the device behind the firewall has to initiate the connection, that a Internet server application (on a Public IP address) to at least manage the initiation of the connection is required, and the Internet server application may also have to act as a relay if the difficulties of NAT is not able to be traversed.
http://en.wikipedia.org/wiki/NAT_traversal
http://en.wikipedia.org/wiki/Peer-to-peer
A good example of this is LogMeIn. Where the application is installed on the computer that needs to be accessible over the Internet, that application communicates with the LogMeIn Internet servers, you can establish a connection to that computer either by initiating through the LogMeIn servers and connecting peer-to-peer over port 80/443 using NAT Traversal (this would be establishing a peer-to-peer connection) or by initiating through the LogMeIn server and the LogMeIn server acting as a relay if peer-to-peer is unable to be established.
Please note; you must have an application (something running) on both ends of the connection on the Internet, there is no other way. Just like FTP that was mentioned earlier (FTP Client, FTP Server)... but in this case it is peer-to-peer (basically you are writing your own Client and Server... or if you have to use a relay... Client--Relay--Server
http://en.wikipedia.org/wiki/LogMeIn
"The service connects the remote desktop and the local computer using SSL over TCP or UDP and utilizing NAT traversal techniques to achieve peer-to-peer connectivity when available."
The part I don't know is can the relay go in both directions; and I am figuring the device behind the firewall must have to constantly manage the open connection to the Internet Server that is the relay. Those are the questions I am wrestling with now.
Also, you may want to check out this post.
C# byte streams through TCP
From that time, till this date I have encounter so many problems with these four kinds of NAT that basically without an external server you cant do anything.
This is because, one computer can never find where the other one is located as suggested in the pic.
Here PC 'A' will never come to know about the port that corresponds to PC 'B' on R2B without an external server.Even more, if somehow u come to know about the ports you are still in a situation that the router wont allow you to access it if the request hasn't been made for your IP.