एक मौजूदा कनेक्शन को दूरस्थ होस्ट द्वारा जबरन बंद कर दिया गया था

Question

मैं एक व्यावसायिक अनुप्रयोग के साथ काम कर रहा हूं, जो संदेश के साथ सॉकेट अपवाद को फेंक रहा है,

एक मौजूदा कनेक्शन को दूरस्थ होस्ट द्वारा जबरन बंद कर दिया गया था

यह क्लाइंट और सर्वर के बीच सॉकेट कनेक्शन के साथ होता है। कनेक्शन जीवित है और अच्छी तरह से है, और डेटा के ढेर को स्थानांतरित किया जा रहा है, लेकिन यह कहीं से भी डिस्कनेक्ट हो जाता है।

क्या किसी ने इससे पहले देखा है? क्या कारण हो सकते हैं? मैं कुछ कारणों का अनुमान लगा सकता हूं, लेकिन क्या इस कोड में अधिक जोड़ने का कोई तरीका है जिससे यह पता लगाया जा सके कि क्या कारण हो सकता है?

किसी भी टिप्पणी / विचारों का स्वागत है।

... सबसे नया ...

मेरे पास कुछ .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 का मतलब है कि शून्य बाइट का एक पैकेट भेजने की कोशिश कर रहा है।

आपको क्या लगता है? यह मुझे लगता है अनिर्णायक हो सकता है, लेकिन शायद किसी और ने इस तरह की बात देखी है?

Comments

बस एक अद्यतन। ऐसा लगता है कि हमारे नेटवर्क सेटअप की वजह से वायरशर्क इस मामले में कटौती नहीं कर रहा है। लेकिन मुझे उम्मीद है कि यह कोशिश करने जा रहा हूं, blogs.msdn.com/dgorti/archive/2005/09/18/471003.aspx जो .NET का उपयोग करके ट्रेस कर रहा है जो कुछ लॉग फ़ाइलों का उत्पादन करना चाहिए। मैं आपको पोस्ट करता रहूंगा ...

— पीटर

Comcast को पी 2 पी ट्रैफ़िक के साथ गड़बड़ करने के लिए नकली "जीरो" पैकेट भेजने के लिए भी जाना जाता है ---

Answer 1

इसका आम तौर पर मतलब है कि दूरस्थ पक्ष ने कनेक्शन बंद कर दिया (आमतौर पर एक टीसीपी / आईपी RSTपैकेट भेजकर )। यदि आप तृतीय-पक्ष एप्लिकेशन के साथ काम कर रहे हैं, तो संभावित कारण हैं:

• आप एप्लिकेशन को विकृत डेटा भेज रहे हैं (जिसमें HTTP सर्वर पर HTTPS अनुरोध भेजना शामिल हो सकता है)
• क्लाइंट और सर्वर के बीच नेटवर्क लिंक किसी कारण से नीचे जा रहा है
• आपने थर्ड-पार्टी एप्लिकेशन में बग को ट्रिगर किया है जिससे यह क्रैश हो गया है
• तीसरे पक्ष के आवेदन में सिस्टम संसाधन समाप्त हो गए हैं

यह संभावना है कि पहला मामला क्या हो रहा है।

समस्या को कम करने के लिए तार पर क्या हो रहा है, यह देखने के लिए आप विंडसर्क को आग लगा सकते हैं।

अधिक विशिष्ट जानकारी के बिना, यह संभावना नहीं है कि यहां कोई भी वास्तव में आपकी बहुत मदद कर सकता है।

Comments

महान। धन्यवाद। तारक के बारे में दूसरी बात। यह इतना डेटा एकत्र करता है, मैं इस तरह से कुछ कैसे फ़िल्टर कर पाऊंगा? यदि वायरशर्क कुछ दिखाता है तो मैं इसे बाद में यहाँ पोस्ट कर सकता हूँ ...

— पीटर

आपको कम से कम आईपी पते और पोर्ट नंबर द्वारा विंडसर डंप को फ़िल्टर करने में सक्षम होना चाहिए। उसके बाद, धारा के अंत में (जहां कुछ गलत हुआ) को देखने के लिए संभवतः सबसे उपयोगी है और पीछे की ओर काम करते हैं जब तक कि आप उस स्थान पर नहीं पहुंच सकते जहां चीजें पहले गड़बड़ हो जाती हैं। शामिल प्रोटोकॉल की जटिलता के आधार पर, यह वास्तव में लगभग असंभव को आसान कर सकता है ...

— RarrRarrRarr

क्या बुलेटेड आइटम के लिए कोई स्रोत है, या नीचे दिए गए गेमर के जवाब ने आपकी सूची को कॉपी किया है?

— जक

कृपया ध्यान दें कि "विकृत डेटा भेजना" का अर्थ सर्वर पर httpsअनुरोध भेजना httpऔर संभवतः इसके विपरीत हो सकता है।

— AXMIM सेप

मेरे मामले में, मुझे यह अपवाद केवल तभी मिल रहा था जब स्थानीय रूप से ऐप चलाते समय आपी को कॉल किया गया था। देव, क्यूए या ठेस वातावरण में कोई समस्या नहीं है। जोड़? HTTP के बजाय स्थानीय रूप से http का उपयोग करना। हमें लगता है कि यह एक लोड बैलेंसर से संबंधित हो सकता है। लेकिन हमने सिर्फ https के लिए ट्रांसफ़ॉर्म के साथ अपने देव, क्यूए और वेब को अपडेट किया है। समस्या सुलझ गयी।

— केरशॉ

Answer 2

TLS 1.2 का उपयोग करके इस त्रुटि को हल किया गया।
आप इस के साथ TLS 1.2 का उपयोग करके अपने आवेदन को बाध्य कर सकते हैं (अपनी सेवा को कॉल करने से पहले इसे निष्पादित करना सुनिश्चित करें):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 

एक अन्य समाधान:
TLS1.2 का उपयोग करने के लिए अपनी स्थानीय मशीन या सर्वर में मजबूत क्रिप्टोग्राफी सक्षम करें क्योंकि डिफ़ॉल्ट रूप से यह अक्षम है इसलिए केवल TLS1.0 का उपयोग किया जाता है।
मजबूत क्रिप्टोग्राफी को सक्षम करने के लिए, इन कमांड को पावरस्ले में व्यवस्थापक विशेषाधिकारों के साथ निष्पादित करें:

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 

इन परिवर्तनों को प्रभावी करने के लिए आपको अपने कंप्यूटर को रिबूट करना होगा।

Comments

आप कई प्रोटोकॉलों का समर्थन करने के लिए एक साथ कई मान जोड़ सकते हैं। तो SSL3 से TLS1.2 तक सब कुछ का समर्थन करने के लिए, SecurityProtocol = (SecurityProtocolType) 4080 सेट करें।

— अबेकस

Answer 3

यह आपके कोड में बग नहीं है। यह .Net के सॉकेट कार्यान्वयन से आ रहा है। यदि आप नीचे के रूप में EndReceive के अतिभारित कार्यान्वयन का उपयोग करते हैं तो आपको यह अपवाद नहीं मिलेगा।

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

Comments

यह ऑपरेटिंग सिस्टम से आ रहा है, और अंततः सहकर्मी से। इस स्पष्टीकरण के लिए यह आवश्यक है कि यह एक सॉफ्टवेयर बग है।

— लोर्न

+1। मेरे C # प्रोग्राम में, मैं अपना सिर पीट रहा था कि EndReceiveजब कोई ग्रेसफुल क्लाइंट टर्मिनेशन हो तो अपवाद क्यों फेंक रहा हूं । Didnt पता है कि यह डिजाइन द्वारा है। मुझे लगता है कि सामान्य कोड प्रवाह में अपवाद को फेंकने के लिए इसका बुरा डिजाइन है। ओवरलोड विधि के लिए भगवान का शुक्र है।

— पवन मंजुनाथ

@MSaudi यह एक एसिंक्रोनस कॉल का उपयोग कर रहा है, सुनिश्चित करें कि आप समझते हैं कि आपका कोड बंद नहीं होगा, जबकि यह डेटा लौटा रहा है। उदाहरण msdn.microsoft.com/en-us/library/bew39x2a(v=vs.110).aspx का उपयोग करता है । मूल रूप से आपके पास एक फ़ंक्शन के StateObjectसाथ एक वर्ग होना चाहिए public byte[] buffer = new byte[1024], public Socket socket;और एक फ़ंक्शन कॉल करना होगा Receive(Socket s), जो करता है StateObject so = new StateObject(); so.socket = s; s.BeginReceive(so.buffer, 0, 256, 0, new AsyncCallback(ReceiveCallback), so); और void ReceiveCallback(IAsyncResult ar)आप उस कोड को कॉल करते हैं, ऊपर।

— vapcguy

@cagatay जब यह एक समाधान प्रदान करता है, तो मैंने कभी भी अतुल्यकालिक तरीकों में मूल्य नहीं देखा, जहां आपको तुरंत पता होना चाहिए कि आपके Sendकुछ और करने से पहले आप क्या कर रहे हैं।

— vapcguy

वास्तव में मैंने पाया कि यह तरीका मूर्खतापूर्ण नहीं है। यह ओपी की त्रुटि का कारण भी बन सकता है: stackoverflow.com/questions/17790612/…

— vapcguy

Answer 4

इस सामान्य कष्टप्रद समस्या का सरल समाधान:

बस अपनी " .context.cs" फ़ाइल (" .context.tt के तहत स्थित) पर जाएं जो आपके" * .edmx "फ़ाइल के नीचे स्थित है)।

फिर, इस लाइन को अपने कंस्ट्रक्टर में जोड़ें:

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

आशा है कि यह उपयोगी है।

Comments

@ यह कहाँ रखना है? और कोई वापसी प्रकार ??

— खलील खलफ

@ फ़र्स्टस्टेप: Coz यह एक कंस्ट्रक्टर है।

— निखिल अग्रवाल

यह केवल एंटिटी फ्रेमवर्क का उपयोग करने वालों को मदद करता है जो इस मुद्दे का सामना कर रहे हैं, न कि उन जो socket.Send(x); byte[] buffer = new byte[1]; socket.Receive(buffer, 0, 1, 0);बाइट्स को पढ़ने के लिए एक साधारण कर रहे हैं , जो कि ओपी का मुद्दा था।

— vapcguy

अगर ENTITY FRAMEWORKकेवल इस समाधान का उपयोग कर काम करता है !!! केवल यह ! धन्यवाद भाई :)

— राव हमास

Answer 5

एक ही बग था। वास्तव में काम के मामले में ट्रैफ़िक को कुछ प्रॉक्सी (मेरे मामले में फ़िडलर) का उपयोग करके भेजा गया था। 4.5.2 से> = 4.6 तक अपडेट किया गया .NET फ्रेमवर्क और अब सब कुछ ठीक है। वास्तविक अनुरोध था:
new WebClient().DownloadData("URL");
अपवाद था:

सॉकेटएक्स अपवाद: एक मौजूदा कनेक्शन को दूरस्थ होस्ट द्वारा जबरन बंद कर दिया गया था

Comments

यह मेरे लिए चीजों को हल करने का एक तरीका था। यह वास्तव में डिफ़ॉल्ट रूप से TLS .NET के किस संस्करण से संबंधित था। 4.5.2 और निचला टीएलएस 1.0 का उपयोग किया, जबकि 4.6 और अधिक से अधिक 1.1 और 1.2 को अनुमति देने के बारे में होशियार हैं। यह भी टीएलएस की आवश्यकता को सर्वर पर 1.0 से हटाकर साबित किया गया था, जिसने इस मुद्दे को भी ठीक किया।

— हॉटएन

Answer 6

इकाई में परिपत्र संदर्भ के कारण मुझे यह अपवाद मिला है। इस इकाई में जो दिखता है

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] जोड़ा। और इससे समस्या हल हो गई।

Answer 7

अगर ANet में रनिंग 4.5.2 सर्विस

मेरे लिए यह समस्या जटिल हो गई थी क्योंकि कॉल एक .Net 4.5.2 सेवा में चल रही थी। मैंने @willmaz सुझाव का पालन किया लेकिन एक नई त्रुटि मिली।

लॉगिंग चालू होने के साथ सेवा को चलाने में, मैंने लक्ष्य साइट के साथ हैंडशेकिंग देखी, जो ठीक है (और वाहक को टोकन भेजेगा) लेकिन पोस्ट कॉल को संसाधित करने के लिए निम्न चरण पर, यह टोकन और साइट को ड्रॉप करने के लिए प्रतीत होगा। के साथ जवाब दें Unauthorized।

यह पता चला कि सेवा पूल क्रेडेंशियल्स के पास टीएलएस (?) को बदलने का अधिकार नहीं था और जब मैंने अपने स्थानीय व्यवस्थापक खाते को पूल में रखा, तो यह सब काम कर गया।

Answer 8

किसी को भी स्ट्रीम से डेटा पढ़ते समय यह अपवाद प्राप्त करने में मदद मिल सकती है। इस तरह के पाश में 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();
    }
}

कुछ समय बाद मुझे पता चला कि अपराधी बफर आकार था, जो बहुत छोटा था और मेरे कमजोर एज़्योर उदाहरण के साथ अच्छा नहीं खेलता था। कोड को बदलने में क्या मदद मिली:

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 कहा जाता है जो किसी कनेक्शन को मारने के लिए जिम्मेदार होता है यदि इसकी ट्रांसफर दर कुछ केबी / सेकंड थ्रेशोल्ड से कम हो जाती है। डिफ़ॉल्ट रूप से, यह सीमा है। 240 kb / सेकंड पर सेट करें। "

इस समस्या को TFS विकास टीम के पुराने ब्लॉगपोस्ट में वर्णित किया गया है और विशेष रूप से IIS की चिंता करता है, लेकिन आपको एक सही दिशा में इंगित कर सकता है। इसमें इस http.sys विशेषता से संबंधित एक पुराने बग का भी उल्लेख किया गया है: लिंक

यदि आप एज़्योर ऐप सेवाओं का उपयोग कर रहे हैं और बफर का आकार बढ़ाने से समस्या समाप्त नहीं होती है, तो अपनी मशीन को भी बढ़ाने की कोशिश करें। आपको कनेक्शन बैंडविड्थ सहित अधिक संसाधन आवंटित किए जाएंगे।

Answer 9

मेरे पास एक ही मुद्दा था और अंततः इसे हल करने में कामयाब रहा। मेरे मामले में, क्लाइंट जो अनुरोध भेजता है, उसके पास एसएसएल प्रमाणित बंधन नहीं है। इसलिए मैंने सर्वर पर पोर्ट के लिए एसएसएल प्रमाणपत्र को बांधकर समस्या को ठीक किया। एक बार जो किया गया था, यह अपवाद दूर चला गया।

Answer 10

जब भी मैंने 10s से कम में डेटा नहीं भेजा या प्राप्त नहीं किया, CIP-प्रोटोकॉल के साथ मेरे आवेदन में यह त्रुटि हुई।

यह आगे की खुली विधि के उपयोग के कारण हुआ। आप किसी अन्य विधि के साथ काम करके, या अपने अग्रेषित-खुले-कनेक्शन को बनाए रखने वाले 10s से कम की अद्यतन दर स्थापित करने से बच सकते हैं।