Hy @all,
Hat irgendjemand noch ne idee warum der fehler kommt? der Timeout kann ausgeschlossen werden. Anbei noch die wichtigsten Infos zur Entwicklung und vielen dank für eure hilfe 😉
greets mex
Problem
Fehlermeldung "System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive."
Gegeben:
Entwickelt mit c# .net-Framework 2.0
IDE: Visual Studio 2005 Prof.
Anwendungstyp: Konsolenanwendung
Aufgabe: Transferieren von Dateien auf einen nicht im netzwerk befindlichen Server mittels FTP
Code:
FtpWebRequest request;
...
// set target of request
request = (FtpWebRequest)WebRequest.Create(targetURI);
// set credential to request
request.Credentials = credential;
// set method to execute to request
request.Method = WebRequestMethods.Ftp.UploadFile;
// set transfer type
request.UseBinary = true;
// if connection isnt closed, dont keep connection after
// a command is executed
request.KeepAlive = false;
#region Transfer file
// define size of the to upload file
request.ContentLength = fileInf.Length;
int bufferlength = 2048;
byte[] buff = new byte[bufferlength];
int contentLen;
// File Stream to read the file to upload
FileStream fs = fileInf.OpenRead();
// Stream object to set the request
Stream strm = request.GetRequestStream();
// Read data in
contentLen = fs.Read(buff, 0, bufferlength);
while (contentLen != 0)
{
// Read data out (To target server)
strm.Write(buff, 0, contentLen);
contentLen = fs.Read(buff, 0, bufferlength);
}
strm.Close();
fs.Close();
#endregion
Auftreten: die Fehler kommt bei Dateien > 70 MB
Testumgebung:
Getestet wurde die Anwendung erfolgreich mit Dateien > 70 MB (allerdings nicht in der Live-Umgebung, sondern in der Entwicklerumgebung aber mit ähnlichen Verhältnissen von Entwickler-Computer zu nicht im netzwerk befindlichem server)
Weitere Informationen:
.net Framework auf Einsatzserver der Konsolenanwendung: 3.5#
Was noch nicht geprüft wurde:
Das Eventlog des Einsatzserver wurde bisher noch nicht gecheckt... erfolgt morgen.
Bisher gelesener Thread:
http://support.microsoft.com/?scid=kb%3Ben-us%3B915599&x=16&y=13
que? como? no entiendo!!!!!
Gehts wenn du die Datei mit einem anderen FTP Client rauflädst?
Die 70 MB machen mich ja schon stutzig.
sers,
danke für den post, aber die 70 mb sind nicht das problem, ich habs gestern mit einer datei 40 mb, eine > 90 mb und einer datei mit > 500 mb getestet. Das funktioniert in der testumgebung fehlerfrei!!!
ich werd mir heute noch die log-einträge (eventlog) anschauen..... aber wie gesagt, für anregungen bin ich dankbar....
greets und schönen tag,
mex
que? como? no entiendo!!!!!
Hallo The_Mexican,
Ich hatte das gleiche Problem. Leider hatte es damals das AntiVirus Gateway das Problem immer verursacht. Ich konnte das Problem umgehen in dem ich die Timeout hochgesetzt hatte.
Vielleicht hilft dir die Info weiter.
@all:
keine einträge in den log-files 😦
@Timuar Zanagar:
danke für die info, aber der timeout ist nicht das problem + dann würde ich vermutlich auch ne timeout exception o. ä. bekommen..... trotzdem vielen dank für die info
wie gesagt, die herausforderung steht, hilfe tips und anregungen immer rein damit 😉
que? como? no entiendo!!!!!
hier ein anderer Thread mit gleichem problem....
es sieht aber nicht nach einer lösung im sinne von "WARUM" es so ist aus:
da meine frage nach synchrone und asynchroner programmierung gelöscht wurde hier eine Antwort
Quelle: Wikipedia
Definition Asynchron
eine Möglichkeit, die ich versuchen werden ist die übertragung asynchron zu implementieren, anstatt synchron weil:
Quelle: http://www.devproconnections.com/article/aspnet2/ftp-transfers.aspx
Large File Transfers
Very large files can take a long time to transfer. Systems that need to support large file transfers may face unique design challenges. When large file transfers are initiated from ASP.NET code, it can cause a lengthy delay for the user and potentially violate one or more timeout periods. ASP.NET provides many standard ways to configure its timeout periods, and for simple situations this may suffice. The FTPWebRequest class also has a ReadWriteTimeout property that is set to 5 minutes by default (300,000 milliseconds). Even if no timeout occurs, it is likely that valuable Web request threads are being tied up unnecessarily during lengthy transfers, thus limiting scalability of the Web server.
More robust and scalable solutions rely on asynchronous communications. ASP.NET provides techniques to help with asynchronous requests, such as the Async page directive. Depending on your needs, that may be sufficient. Cutting-edge technologies such as AJAX may also be tempting solutions. Additionally, the .NET Framework has long provided useful patterns for building asynchronous solutions, such as the BeginInvoke and EndInvoke methods. If you ve done this kind of development before, you ll find the FTPWebRequest s built-in asynchronous methods to be quite intuitive. Specifically, these FTPWebRequest members are named BeginGetResponse, EndGetResponse, BeginGetRequestStream, and EndGetRequestStream.
que? como? no entiendo!!!!!
Das funktioniert in der testumgebung fehlerfrei!!!
Mit deinem System auf einem anderen Rechner? Oder mit einem anderen FTP-Server auf deinem Rechner?
Ich meinte ja nicht dass es allgemein an 70 MB liegt, sondern dass genau deine Umgebung mit den 70 MB oder mit irgendwas das damit zusammenhängt ein Problem hat.
Ist der FTP Server denn so konfiguriert, dass er ausreichend Idle Time erlaubt, bevor er die Verbindung trennt ? Ich hatte früher bei meinem ehemaligen Arbeitgeber immer das Problem, dass FTP-Uploads die ich über Nacht für die Amerikaner angestoßen habe, irgendwann fehlgeschlagen sind, da der FTP nach einer gewissen Zeit ein Kommando haben wollte und wenn keins kam, er die Verbindung unterbrach.
"It is not wise to be wise" - Sun Tzu