การเชื่อมต่อที่มีอยู่ถูกบังคับให้ปิดโดยโฮสต์ระยะไกล

ฉันกำลังทำงานกับแอพพลิเคชั่นทางการค้าที่ใช้ SocketException พร้อมข้อความ

การเชื่อมต่อที่มีอยู่ถูกบังคับให้ปิดโดยโฮสต์ระยะไกล

สิ่งนี้เกิดขึ้นกับการเชื่อมต่อซ็อกเก็ตระหว่างไคลเอนต์และเซิร์ฟเวอร์ การเชื่อมต่อยังมีชีวิตอยู่และดีและมีการถ่ายโอนข้อมูลจำนวนมาก แต่ก็จะถูกตัดการเชื่อมต่อออกจากที่ใดที่หนึ่ง

มีใครเห็นสิ่งนี้มาก่อนหรือไม่ สาเหตุอาจเกิดจากอะไร ฉันสามารถเดาสาเหตุบางอย่างได้ แต่ก็มีวิธีเพิ่มรหัสนี้ลงไปอีกไหมเพื่อหาสาเหตุที่เป็นไปได้

ความคิดเห็น / ความคิดใด ๆ ยินดีต้อนรับ

... ใหม่ล่าสุด ...

ฉันมีการบันทึกจากการติดตาม. NET บางรายการ

System.Net.Sockets Verbose: 0 : [8188] Socket#30180123::Send() DateTime=2010-04-07T20:49:48.6317500Z

System.Net.Sockets Error: 0 : [8188] Exception in the Socket#30180123::Send - An existing connection was forcibly closed by the remote host DateTime=2010-04-07T20:49:48.6317500Z 

System.Net.Sockets Verbose: 0 : [8188] Exiting Socket#30180123::Send() -> 0#0

จากส่วนอื่น ๆ ของการบันทึกฉันได้เห็นความจริงที่ระบุว่า '0 # 0' หมายถึงการส่งแพ็กเก็ตที่มีความยาว 0 ไบต์ แต่นั่นหมายความว่าอย่างไร

ความเป็นไปได้อย่างหนึ่งอย่างใดอย่างหนึ่งเกิดขึ้นและฉันไม่แน่ใจ

1) การเชื่อมต่อถูกปิด แต่ข้อมูลถูกเขียนลงในซ็อกเก็ตดังนั้นการสร้างข้อยกเว้นข้างต้น 0 # 0 นั้นหมายความว่าไม่มีสิ่งใดถูกส่งเนื่องจากซ็อกเก็ตปิดอยู่แล้ว

2) การเชื่อมต่อยังคงเปิดอยู่และแพ็คเก็ตของศูนย์ไบต์จะถูกส่ง (เช่นรหัสมีข้อผิดพลาด) และ 0 # 0 หมายความว่าแพ็คเก็ตของศูนย์ไบต์พยายามที่จะส่ง

คุณคิดยังไง มันอาจจะสรุปไม่ได้ว่าฉันเดา แต่บางทีคนอื่นเห็นสิ่งนี้?

โดยทั่วไปหมายความว่าด้านระยะไกลปิดการเชื่อมต่อ (โดยปกติจะส่งRSTแพ็คเก็ตTCP / IP ) หากคุณกำลังทำงานกับแอปพลิเคชันบุคคลที่สามสาเหตุที่เป็นไปได้คือ:

• คุณกำลังส่งข้อมูลที่มีรูปแบบไม่ถูกต้องไปยังแอปพลิเคชัน (ซึ่งอาจรวมถึงการส่งคำขอ HTTPS ไปยังเซิร์ฟเวอร์ HTTP)
• ลิงก์เครือข่ายระหว่างไคลเอนต์และเซิร์ฟเวอร์กำลังปิดตัวลงด้วยเหตุผลบางประการ
• คุณได้เรียกจุดบกพร่องในแอปพลิเคชันบุคคลที่สามที่ทำให้เกิดข้อผิดพลาด
• แอปพลิเคชันบุคคลที่สามหมดทรัพยากรระบบ

เป็นไปได้ว่ากรณีแรกคือสิ่งที่เกิดขึ้น

คุณสามารถยิงWiresharkเพื่อดูว่าเกิดอะไรขึ้นบนเส้นลวดเพื่อ จำกัด ปัญหาให้แคบลง

หากไม่มีข้อมูลที่เฉพาะเจาะจงมากขึ้นมันไม่น่าเป็นไปได้ที่ทุกคนที่นี่จะสามารถช่วยเหลือคุณได้มาก

การใช้ TLS 1.2 แก้ไขข้อผิดพลาดนี้
คุณสามารถบังคับให้แอปพลิเคชันของคุณใช้ TLS 1.2 ด้วยสิ่งนี้ (ตรวจสอบให้แน่ใจว่าได้ดำเนินการก่อนที่จะเรียกใช้บริการของคุณ)

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 

โซลูชันอื่น:
เปิดใช้งานการเข้ารหัสที่รัดกุมในเครื่องหรือเซิร์ฟเวอร์ของคุณเพื่อใช้ TLS1.2 เนื่องจากโดยค่าเริ่มต้นจะถูกปิดใช้งานดังนั้นจะใช้ TLS1.0 เท่านั้น
ในการเปิดใช้งานการเข้ารหัสที่รัดกุมดำเนินการ commande เหล่านี้ใน PowerShell ด้วยสิทธิ์ผู้ดูแลระบบ:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord 

คุณต้องรีบูตคอมพิวเตอร์เพื่อให้การเปลี่ยนแปลงเหล่านี้มีผล

นี่ไม่ใช่ข้อผิดพลาดในรหัสของคุณ มันมาจากการใช้ Socket ของ. Net หากคุณใช้การใช้งานมากเกินไปของ EndReceive ด้านล่างคุณจะไม่ได้รับข้อยกเว้นนี้

    SocketError errorCode;
    int nBytesRec = socket.EndReceive(ar, out errorCode);
    if (errorCode != SocketError.Success)
    {
        nBytesRec = 0;
    }

วิธีง่ายๆสำหรับปัญหาที่น่ารำคาญนี้:

เพียงไปที่ไฟล์ ".context.cs" (อยู่ใต้ " .context.tt" ซึ่งอยู่ใต้ไฟล์ "* .edmx" ของคุณ)

จากนั้นเพิ่มบรรทัดนี้ลงในตัวสร้างของคุณ:

public DBEntities() 
        : base("name=DBEntities") 
    { 
        this.Configuration.ProxyCreationEnabled = false; // ADD THIS LINE !
    }

หวังว่านี่จะเป็นประโยชน์

มีข้อผิดพลาดเดียวกัน ใช้งานได้จริงในกรณีที่ปริมาณการใช้ข้อมูลถูกส่งโดยใช้พร็อกซีบางส่วน (พู้ทำเล่นในกรณีของฉัน) อัปเดตกรอบงาน. NET จาก 4.5.2 เป็น> = 4.6 และตอนนี้ทุกอย่างทำงานได้ดี คำขอที่แท้จริงคือ:
new WebClient().DownloadData("URL");
ข้อยกเว้นคือ:

SocketException: การเชื่อมต่อที่มีอยู่ถูกบังคับให้ปิดโดยโฮสต์ระยะไกล

ฉันได้รับข้อยกเว้นนี้เนื่องจากการอ้างอิงแบบวงกลมในเอนทิตีในเอนทิตีที่มีลักษณะเหมือน

public class Catalog
{
    public int Id { get; set; }
    public int ParentId { get; set; }
    public Catalog Parent { get; set; }
    public ICollection<Catalog> ChildCatalogs { get; set; }
}

ฉันเพิ่ม [IgnoreDataMemberAttribute] ให้กับคุณสมบัติหลัก และนั่นก็แก้ปัญหาได้

ถ้าใช้บริการ A .Net 4.5.2

สำหรับฉันแล้วปัญหานี้เกิดขึ้นเนื่องจากการโทรทำงานในบริการ. Net 4.5.2 ฉันทำตามคำแนะนำ @willmaz แต่มีข้อผิดพลาดใหม่

ในการเรียกใช้บริการโดยเปิดการบันทึกฉันดูการจับมือกับไซต์เป้าหมายจะเริ่มต้นตกลง (และส่งโทเค็นผู้ถือ) แต่ในขั้นตอนต่อไปนี้เพื่อประมวลผลการโทรโพสต์ดูเหมือนว่าจะลดโทเค็นรับรองความถูกต้องแล้ว Unauthorizedตอบกลับด้วย

มันกลับกลายเป็นว่าข้อมูลประจำตัวของกลุ่มการบริการไม่มีสิทธิ์ในการเปลี่ยน TLS (?) และเมื่อฉันใส่บัญชีผู้ดูแลระบบภายในเครื่องของฉันลงในกลุ่มการทำงานทั้งหมดก็ใช้งานได้

สำหรับทุกคนที่ได้รับข้อยกเว้นนี้ในขณะที่อ่านข้อมูลจากสตรีมสิ่งนี้อาจช่วยได้ ฉันได้รับข้อยกเว้นนี้เมื่ออ่าน HttpResponseMessage ในลูปแบบนี้

using (var remoteStream = await response.Content.ReadAsStreamAsync())
using (var content = File.Create(DownloadPath))
{
    var buffer = new byte[1024];
    int read;

    while ((read = await remoteStream.ReadAsync(buffer, 0, buffer.Length)) != 0)
    {
        await content.WriteAsync(buffer, 0, read);
        await content.FlushAsync();
    }
}

หลังจากระยะเวลาหนึ่งฉันพบผู้กระทำผิดคือขนาดบัฟเฟอร์ซึ่งเล็กเกินไปและเล่นได้ไม่ดีกับอินสแตนซ์ Azure ที่อ่อนแอของฉัน สิ่งที่ช่วยได้คือเปลี่ยนรหัสเป็น:

using (Stream remoteStream = await response.Content.ReadAsStreamAsync())
using (FileStream content = File.Create(DownloadPath))
{
    await remoteStream.CopyToAsync(content);
}

CopyTo ()วิธีการมีขนาดบัฟเฟอร์เริ่มต้นของ 81920 บัฟเฟอร์ที่ใหญ่กว่าเร่งกระบวนการและข้อผิดพลาดหยุดทันทีส่วนใหญ่เนื่องจากความเร็วในการดาวน์โหลดโดยรวมเพิ่มขึ้น แต่ทำไมความเร็วในการดาวน์โหลดถึงสำคัญในการป้องกันข้อผิดพลาดนี้?

อาจเป็นไปได้ว่าคุณถูกตัดการเชื่อมต่อจากเซิร์ฟเวอร์เนื่องจากความเร็วในการดาวน์โหลดลดลงต่ำกว่าเกณฑ์ขั้นต่ำที่เซิร์ฟเวอร์กำหนดไว้ให้อนุญาต ตัวอย่างเช่นในกรณีที่แอปพลิเคชันที่คุณดาวน์โหลดไฟล์ถูกโฮสต์อยู่บน IIS อาจเป็นปัญหากับการกำหนดค่า http.sys:

"Http.sys เป็นโพรโทคอล http โพรโทคอลที่ IIS ใช้เพื่อทำการสื่อสาร http กับไคลเอนต์มีตัวจับเวลาที่เรียกว่า MinBytesPerSecond ที่รับผิดชอบฆ่าการเชื่อมต่อถ้าอัตราการถ่ายโอนลดลงต่ำกว่าขีด จำกัด kb / วินาทีบางตัว ตั้งค่าเป็น 240 kb / วินาที "

ปัญหานี้ได้อธิบายไว้ใน blogpost เก่านี้จากทีมพัฒนา TFS และเกี่ยวข้องกับ IIS โดยเฉพาะ แต่อาจนำคุณไปในทิศทางที่ถูกต้อง นอกจากนี้ยังกล่าวถึงข้อบกพร่องเก่า ๆ ที่เกี่ยวข้องกับแอตทริบิวต์ http.sys นี้: ลิงก์

ในกรณีที่คุณใช้บริการแอป Azure และการเพิ่มขนาดบัฟเฟอร์ไม่ได้ช่วยขจัดปัญหาให้ลองปรับขนาดเครื่องของคุณด้วย คุณจะได้รับการจัดสรรทรัพยากรมากขึ้นรวมถึงแบนด์วิดธ์การเชื่อมต่อ

ฉันมีปัญหาเดียวกันและจัดการเพื่อแก้ไขในที่สุด ในกรณีของฉันพอร์ตที่ไคลเอนต์ส่งการร้องขอไปไม่มีใบรับรอง SSL ที่เชื่อมโยง ดังนั้นฉันจึงแก้ไขปัญหาโดยผูกใบรับรอง SSL กับพอร์ตที่ฝั่งเซิร์ฟเวอร์ เมื่อเสร็จแล้วข้อยกเว้นนี้ก็หายไป

ข้อผิดพลาดนี้เกิดขึ้นในแอปพลิเคชันของฉันที่มีโปรโตคอล CIP เมื่อใดก็ตามที่ฉันไม่ได้ส่งหรือรับข้อมูลในเวลาน้อยกว่า 10 วินาที

นี่คือสาเหตุมาจากการใช้วิธีการเปิดไปข้างหน้า คุณสามารถหลีกเลี่ยงปัญหานี้ได้ด้วยการทำงานกับวิธีอื่นหรือติดตั้งอัตราการอัพเดทน้อยกว่า 10 วินาทีที่รักษาการเชื่อมต่อไปข้างหน้าของคุณ