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


103

मेरे पास एक सर्वर ऐप है और कभी-कभी, जब क्लाइंट कनेक्ट करने की कोशिश करता है, तो मुझे निम्नलिखित त्रुटि मिलती है:

यहां छवि विवरण दर्ज करें

नोट: "क्लाइंट से स्ट्रीम प्राप्त नहीं कर सका या लॉगिन फेल" एक पाठ है जिसे मेरे द्वारा स्टेटमेंट में जोड़ा गया है

और वह रेखा जिस पर यह रुकता है (sThread: लाइन 96) है:

tcpClient = (TcpClient)client;
clientStream = tcpClient.GetStream();
sr = new StreamReader(clientStream);
sw = new StreamWriter(clientStream);

// line 96:                 
a = sr.ReadLine();

इस समस्या के कारण क्या हो सकते हैं? ध्यान दें कि यह हर समय नहीं होता है

जवाबों:


63

इस त्रुटि का आमतौर पर मतलब है कि लक्ष्य मशीन चल रही है, लेकिन जिस सेवा से आप जुड़ने की कोशिश कर रहे हैं वह उपलब्ध नहीं है। (या तो यह बंद हो गया, दुर्घटनाग्रस्त हो गया, या किसी अन्य अनुरोध के साथ व्यस्त है।)

अंग्रेजी में: मशीन से कनेक्शन (रिमोट होस्ट / सर्वर / पीसी जिसे सर्विस चलती है) बनाया गया था, लेकिन चूंकि उस मशीन पर सेवा उपलब्ध नहीं थी , इसलिए मशीन को यह नहीं पता था कि अनुरोध के साथ क्या करना है।

यदि मशीन से कनेक्शन उपलब्ध नहीं था, तो आपको एक अलग त्रुटि दिखाई देगी। मैं भूल गया कि यह क्या है, लेकिन यह "सेवा अनुपलब्ध" या "अनुपलब्ध" की तर्ज पर है।

संपादित करें - जोड़ा गया

यह संभव है कि यह पोर्ट को अवरुद्ध करने वाले फ़ायरवॉल के कारण हो रहा है, लेकिन यह कहते हुए कि आप इसे रुक-रुक कर बोल रहे हैं ("कभी-कभी जब क्लाइंट कनेक्ट करने का प्रयास करता है"), तो यह बहुत संभावना नहीं है। मैंने इसे मूल रूप से शामिल नहीं किया क्योंकि मैंने उत्तर देने से पहले इसे मानसिक रूप से खारिज कर दिया था।


1
बात यह है कि जब मैं सर्वर शुरू करता हूं तो कुछ ऐसे होते हैं जैसे 50 क्लाइंट मेरे सर्वर से जुड़ते हैं। मैंने किसी क्लाइंट को स्वीकार करते समय एक तरह के प्रतीक्षा संकेत को लागू किया है .. जबकि कुछ (Program.waitToFinishLoginAtClient == true && ajutor <30) {Thread.Sleep (300); Ajutor ++; } ग्राहक = this.tcpListener.AcceptTcpClient (); प्रोग्राम.वाइटटॉफिनिशलोगिनएट क्लिएंट = सच; ........... और Program.waitToFinishAtClient ग्राहक में शामिल धागे में संशोधित हो जाता है
एलेक्स

क्या यह "प्रतीक्षा" समस्या हो सकती है?
एलेक्स

1
क्या मुझे इसे बस होने देना चाहिए? इंतज़ार नही ?
एलेक्स

1
मुझे लगता है कि प्रतीक्षा समस्या है। मुझे यकीन है कि आपके कोड का पर्याप्त पता नहीं है, लेकिन यह सुनिश्चित होने की संभावना है। बस के रूप में उत्सुक है कि क्या आप अपनी खुद की सेवा "कठिन रास्ता" बनाया या यदि आप इस के लिए WCF या यहां तक ​​कि Remoting का उपयोग कर रहे हैं ...
डेविड

यहाँ कोड की थोड़ी सी नाइट के आधार पर, यह मुझे "प्रतीक्षा" समस्या की तरह दिखता है, यदि इसे प्रत्येक कॉन्सेप्टन के लिए एक अलग थ्रेड के अंदर रखा जा सकता है। यदि ऐसा लगता है कि सही है, तो यहां मल्टी-थ्रेडिंग के साथ एक बहु-थ्रेडेड टीसीपी सेवा का एक उदाहरण है जो आपकी मदद कर सकता है: switchonthecode.com/tutorials/…
डेविड

180

वेब-सेवा पर कॉल करते समय मुझे यह त्रुटि मिली। यह मुद्दा परिवहन स्तर की सुरक्षा से भी संबंधित था। मैं एक वेब परियोजना के माध्यम से वेब-सेवा को कॉल कर सकता हूं, लेकिन जब एक परीक्षण परियोजना में समान कोड का पुन: उपयोग कर रहा हूं तो मुझे एक WebException मिलेगा जिसमें यह संदेश शामिल था। कॉल को हल करने से पहले निम्न पंक्ति जोड़ना समस्या का हल:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

संपादित करें

System.Net.ServicePointManager.SecurityProtocol - यह संपत्ति केवल सुरक्षित हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTPS) योजना का उपयोग करने वाले नए कनेक्शन के लिए उपयोग करने के लिए सिक्योर सॉकेट्स लेयर (SSL) या ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) प्रोटोकॉल के संस्करण का चयन करती है; मौजूदा कनेक्शन नहीं बदले गए हैं।

मेरा मानना SecurityProtocolहै कि प्रोटोकॉल संस्करण का चयन करते समय TLS हैंडशेक के दौरान कॉन्फ़िगरेशन महत्वपूर्ण है।

टीएलएस हैंडशेक - इस प्रोटोकॉल का उपयोग टीएलएस द्वारा वास्तविक एप्लिकेशन डेटा के आदान-प्रदान के लिए दोनों पक्षों द्वारा आवश्यक सभी सूचनाओं के आदान-प्रदान के लिए किया जाता है।

ClientHello - एक क्लाइंट एक क्लाइंटहेल्लो संदेश भेजता है, जो उच्चतम TLS प्रोटोकॉल संस्करण का समर्थन करता है, जो उसका समर्थन करता है ...

ServerHello - सर्वर चुने हुए प्रोटोकॉल संस्करण वाले सर्वरहेलो संदेश के साथ प्रतिक्रिया करता है ... चुना हुआ प्रोटोकॉल संस्करण उच्चतम होना चाहिए जो क्लाइंट और सर्वर दोनों का समर्थन करता है। उदाहरण के लिए, यदि क्लाइंट टीएलएस संस्करण 1.1 का समर्थन करता है और सर्वर 1.2 संस्करण का समर्थन करता है, तो संस्करण 1.1 का चयन किया जाना चाहिए; संस्करण 1.2 का चयन नहीं किया जाना चाहिए।


8
इसने मुझे बचाया! धन्यवाद दोस्त। अपने डिबगर में मैं परीक्षण करते समय एक https सेवा को कॉल करने की कोशिश कर रहा हूं और ओपी होने की समस्या थी।
ब्लेयर होम्स

6
क्या हम इस बारे में अधिक जानते हैं कि यह कैसे / क्यों काम करता है? मैं एक PostAsync कॉल के साथ संघर्ष कर रहा हूं और यह मेरी त्रुटि को ठीक करने के लिए प्रकट होता है। खुशी है कि यह काम किया है, लेकिन मैं यह भी जानना चाहूंगा कि क्यों।
केविन मैटलॉक

1
@HansVonn इसके लिए धन्यवाद! मुझे एक टन समय बचा लिया - इस संबंध में कि यह क्यों काम करता है यह सिर्फ टीएलएस संस्करण को सीमित कर रहा है जिसे आप कनेक्ट करते समय उपयोग कर रहे हैं।
भ्रमित

1
विश्वास नहीं कर सकता यह मुझे एक बार फिर मिला! धन्यवाद
सर्जियो ए।

2
धन्यवाद! यह मुझे पागल कर रहा था।
1914

34

मेरी विशिष्ट स्थिति यह थी कि एज़्योर ऐप सेवा का न्यूनतम टीएलएस संस्करण 1.2 में बदल गया था

मुझे नहीं पता कि यह अभी से डिफ़ॉल्ट है, लेकिन इसे 1.0 में बदलकर इसे काम कर दिया।

आप "एसएसएल सेटिंग्स" के अंदर सेटिंग तक पहुंच सकते हैं।


7
ओह माई गॉड थैंक यू सो मच! मैं sooo लंबे समय के लिए इस पर अटक गया है, और मैंने वेब ऐप की एसएसएल सेटिंग्स की जांच की, और न्यूनतम 1.0 के बजाय 1.2 पर सेट किया गया था। जब मैंने इसे वापस 1.0 में बदल दिया और वेब ऐप को फिर से शुरू किया, तो यह काम कर गया! आपको बहुत - बहुत धन्यवाद!
मेसन

1
बहुत बहुत धन्यवाद, @ ह्यूगो-हिलारियो, आश्चर्यजनक रूप से इसने मेरे लिए भी काम किया! इस तरह के एक मुश्किल समाधान को खोजने के लिए आपने पृथ्वी पर कैसा प्रबंधन किया! : डी
होजय

@hosjay यह मेरे लिए भी एक नर्क था :)
ह्यूगो हिलोरियो

3
मेरे दिन के साथी को बचाया!
नितेश

मेरे पास मेरे
एज़्योर

17

निश्चित नहीं है कि इन ब्लॉग पोस्टों में से कौन सी फ़िक्सेस ने मदद की, लेकिन उनमें से एक ने मेरे लिए इस मुद्दे को हल किया ...

http://briancaos.wordpress.com/2012/07/06/unable-to-read-data-from-the-transport-connection-the-connection-was-closed/

इस ट्रिक ने मुझे एक WebRequest का उपयोग करना छोड़ दिया और इसके बजाय एक HttpWebRequest का उपयोग करना पड़ा। HttpWebRequest मुझे 3 महत्वपूर्ण सेटिंग्स के साथ खेलने की अनुमति देता है:

तथा

http://briancaos.wordpress.com/2012/06/15/an-existing-connection-was-forcibly-closed-by-the-remote-host/

  • चरण 1: निष्क्रिय रखें
  • चरण 2: सेट करें प्रोटोकॉल वर्जन 10 तक
  • चरण 3: सेवा बिंदुओं की संख्या को सीमित करना

1
यह उत्तर वही है जो मेरे लिए इसी समस्या को हल करता है। मैंने IIS7 में Http रिस्पांस
हेडर्स

मुझे यह जोड़ना चाहिए कि मुझे यह कोड उस वेब सेवा के लिए Reference.cs में भी जोड़ना था जो उस व्यवहार के लिए थी। संरक्षित ओवरराइड System.Net.WebRequest GetWebRequest (Uri uri) {System.Net.ttpWebRequest webRequest = (System.Net.HttpWebRequest) base.GebWequest (uri); webRequest.KeepAlive = false; वापसी webRequest; }
drzounds

11

हमारे एक सर्वर से HTTPS सेवाओं के लिए कॉल " परिवहन कनेक्शन से डेटा पढ़ने में असमर्थ: एक मौजूदा कनेक्शन को जबरन बंद कर दिया गया " अपवाद को फेंक रहा था । HTTP सेवा, हालांकि, ठीक काम किया। Wireshark का उपयोग यह देखने के लिए किया जाता है कि यह TLS हैंडशेक विफलता थी। समाप्त किया जा रहा है कि सर्वर पर सिफर सूट को अद्यतन करने की आवश्यकता है।


मेरे साथ यही हो रहा था। A, SSL प्रमाणपत्र के लिए एक समय सीमा समाप्त प्रमाणपत्र भेज रहा था। प्रमाणपत्र का नवीनीकरण और काम किया।
गिलहर्मे डे जीसस सैंटोस

8

"हंस वॉन" उत्तरों के अनुसार।

कॉल को हल करने से पहले निम्न पंक्ति जोड़ना समस्या का हल:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

सुरक्षा प्रोटोकॉल जोड़ने और ठीक काम करने के बाद लेकिन मुझे हर एपीआई कॉल से पहले जोड़ना होगा जो स्वस्थ नहीं है। मैं सिर्फ .net फ्रेमवर्क संस्करण को कम से कम 4.6 अपग्रेड करता हूं और उम्मीद के मुताबिक काम करते हुए हर एपीआई कॉल से पहले जोड़ने की आवश्यकता नहीं होती है।


1
आपका बहुत बहुत धन्यवाद। आपने मेरा दिन बना दिया। यह कुछ के लिए उपयोगी हो सकता है यदि मैं उल्लेख करता हूं कि इससे पहले मैंने फ़ायरवॉल को निष्क्रिय करने और ServicePointManager.ServerCertificateValidationCallback को जोड़ने का परीक्षण किया था, लेकिन गैर काम नहीं किया।
Tekin

5

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

मैंने एक वीएम का क्लोन बनाया था और इसे नए आईपी पते के साथ एक अलग नेटवर्क पर शुरू किया था, लेकिन आईआईएस में बाइंडिंग नहीं बदली। फ़िडलर मुझे दिखा रहा था "परिवहन कनेक्शन से डेटा पढ़ने में असमर्थ: एक मौजूदा कनेक्शन दूरस्थ होस्ट द्वारा जबरन बंद किया गया था" और IE मुझे "टीएलएस 1.0, टीएलएस 1.1, और टीएलएस 1.2 उन्नत सेटिंग्स में चालू करें" बता रहा था। नए आईपी पते के लिए बाध्यकारी को बदलना मेरे लिए इसे हल कर दिया।


2

किसी कारण से, सर्वर से कनेक्शन खो गया था। यह हो सकता है कि सर्वर ने कनेक्शन को स्पष्ट रूप से बंद कर दिया था, या सर्वर पर बग के कारण यह अप्रत्याशित रूप से बंद हो गया। या क्लाइंट और सर्वर के बीच कुछ (एक स्विच या राउटर) ने कनेक्शन को गिरा दिया।

यह सर्वर कोड हो सकता है जो समस्या का कारण बना, और यह नहीं हो सकता है। यदि आपके पास सर्वर कोड तक पहुंच है, तो क्लाइंट कनेक्शन बंद होने पर आपको यह बताने के लिए कुछ डिबगिंग डाल सकते हैं। कनेक्शन कब और क्यों गिराए जा रहे हैं, इसके कुछ संकेत आपको दे सकते हैं।

क्लाइंट पर, आपको किसी भी समय सर्वर के विफल होने की संभावना को ध्यान में रखने के लिए अपना कोड लिखना होगा। यही कारण है कि यह है: नेटवर्क कनेक्शन स्वाभाविक अविश्वसनीय हैं।


2

इससे मेरी समस्या हल हो गई। अनुरोध किए जाने से पहले मैंने इस पंक्ति को जोड़ा:

System.Net.ServicePointManager.Expect100Continue = false;

ऐसा लगता था कि सर्वर के रास्ते में एक प्रॉक्सी थी जो 100-जारी व्यवहार का समर्थन नहीं करती थी।


1

मुझे वह समस्या अतीत में मिलती है। मैं PostgreSQL का उपयोग कर रहा हूं और जब मैं अपना कार्यक्रम चलाता हूं, तो कभी-कभी यह कनेक्ट होता है और कभी-कभी यह इस तरह एक त्रुटि फेंकता है।

जब मैं अपने कोड के साथ प्रयोग करता हूं, तो मैंने अपना कनेक्शन कोड सार्वजनिक प्रपत्र के नीचे पहली पंक्ति में रखा। यहाँ एक उदाहरण है:

इससे पहले:

    public Form1()
        {
        //HERE LIES SOME CODES FOR RESIZING MY CONTROLS DURING RUNTIME
        //CODE
        //CODE AGAIN
        //ANOTHER CODE
        //CODE NA NAMAN
        //CODE PA RIN!





        //Connect to Database to generate auto number
        NpgsqlConnection iConnect = new NpgsqlConnection("Server=localhost;Port=5432;User ID=postgres;Password=pass;Database=DB");
        iConnect.Open();
        NpgsqlCommand iQuery = new NpgsqlCommand("Select * from table1", iConnect);
        NpgsqlDataReader iRead = iQuery.ExecuteReader();
        NpgsqlDataAdapter iAdapter = new NpgsqlDataAdapter(iQuery);

        DataSet iDataSet = new DataSet();
        iAdapter.Fill(iDataSet, "ID");

        MessageBox.Show(iDataSet.Tables["ID"].Rows.Count.ToString());
        }

अभी:

    public Form1()
        {
        //Connect to Database to generate auto number
        NpgsqlConnection iConnect = new NpgsqlConnection("Server=localhost;Port=5432;User ID=postgres;Password=pass;Database=DB");
        iConnect.Open();
        NpgsqlCommand iQuery = new NpgsqlCommand("Select * from table1", iConnect);
        NpgsqlDataReader iRead = iQuery.ExecuteReader();
        NpgsqlDataAdapter iAdapter = new NpgsqlDataAdapter(iQuery);

        DataSet iDataSet = new DataSet();
        iAdapter.Fill(iDataSet, "ID");

        MessageBox.Show(iDataSet.Tables["ID"].Rows.Count.ToString());





        //HERE LIES SOME CODES FOR RESIZING MY CONTROLS DURING RUNTIME
        //CODE
        //CODE AGAIN
        //ANOTHER CODE
        //CODE NA NAMAN
        //CODE PA RIN!

        }

मुझे लगता है कि कुछ भी करने से पहले कार्यक्रम को पहले कनेक्शन को पढ़ना चाहिए, मुझे नहीं पता, अगर मैं गलत हूं तो मुझे सही करें। लेकिन मेरे शोध के अनुसार, यह एक कोड समस्या नहीं है - यह वास्तव में मशीन से ही था।

हैप्पी कोडिंग!


1
System.Net.ServicePointManager.Expect100Continue = false;

यह समस्या कभी-कभी वेब सर्वर पर प्रॉक्सी सर्वर के लागू होने के कारण होती है। सेंड सर्विस को कॉल करने से पहले इस लाइन को लगाकर प्रॉक्सी सर्वर को बायपास करें।


0

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


0

हमारे पास एक समान मुद्दा था जिससे एक ग्राहक की वेबसाइट हमारी वेब एपीआई सेवा से जुड़ने की कोशिश कर रही थी और उसी संदेश को प्राप्त कर रही थी। यह पूरी तरह से नीले रंग से बाहर होने लगा जब आईआईएस चल रहे सर्वर पर कोई कोड परिवर्तन या विंडोज अपडेट नहीं था।

हमारे मामले में यह पता चला है कि कॉलिंग वेबसाइट .Net के एक संस्करण का उपयोग कर रही थी जो केवल टीएलएस 1.0 का समर्थन करती थी और किसी कारण से हमारे आईआईएस को बंद करने वाले सर्वर ने टीएलएस 1.0 कॉल स्वीकार करना बंद कर दिया था। यह जानने के लिए कि हमें IIS के सर्वर पर रजिस्ट्री के माध्यम से TLS को स्पष्ट रूप से सक्षम करना था और फिर उस सर्वर को पुनः आरंभ करें। ये हैं रेज कीज:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.0\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.0\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.1\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.1\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

If that doesn't do it, you could also experiment with adding the entry for SSL 2.0:


    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
    "DisabledByDefault"=dword:00000000
    "Enabled"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
    "DisabledByDefault"=dword:00000000
    "Enabled"=dword:00000001

एक और सवाल का मेरा जवाब यहाँ में यह शक्तिकृत लिपि है जिसका उपयोग हम प्रविष्टियों को जोड़ने के लिए करते हैं:

नोट: पुराने सुरक्षा प्रोटोकॉल को सक्षम करना एक अच्छा विचार नहीं है, हमारे मामले में सही उत्तर ग्राहक वेबसाइट को यह अपडेट करने के लिए था कि यह टीएलएस 1.2 का उपयोग करने के लिए कोड है, लेकिन ऊपर दी गई रजिस्ट्री प्रविष्टियां पहले स्थान पर समस्या का निदान करने में मदद कर सकती हैं।


0

मेरे साथ ऐसा होने का कारण यह था कि मेरे डीआई प्रदाता में एक पुनरावर्ती निर्भरता थी। मेरे मामले में मेरे पास था:

services.AddScoped(provider => new CfDbContext(builder.Options));
services.AddScoped(provider => provider.GetService<CfDbContext>());

फिक्स सिर्फ दूसरी स्कॉप्ड सर्विस रजिस्ट्रेशन को हटाना था

services.AddScoped(provider => new CfDbContext(builder.Options));

0

यदि आपके पास डोमेन पर एक https प्रमाणपत्र है, तो सुनिश्चित करें कि आपके पास IIS में डोमेन नाम के लिए https बाइंडिंग है। IIS में -> अपने डोमेन का चयन करें -> बाइंडिंग साइट पर क्लिक करें साइट विंडो खुल जाती है। Https के लिए बाइंडिंग जोड़ें।


0

इसी तरह की समस्या थी और मैं किस ऐप का उपयोग करता था और अगर हम फ़ायरवॉल / लोड बैलेंसर को दरकिनार करते हैं या इस पर निर्भर करते हुए निम्नलिखित त्रुटियाँ हो रही थीं:

HTTPS हैंडशेक [blah] (# 136 के लिए) विफल रहा। System.IO.IOException ट्रांसपोर्ट कनेक्शन के डेटा को पढ़ने में असमर्थ: एक मौजूदा कनेक्शन को रिमोट होस्ट द्वारा जबरन बंद कर दिया गया था

तथा

ReadResponse () विफल: सर्वर ने इस अनुरोध के लिए पूर्ण प्रतिक्रिया नहीं दी। सर्वर 0 बाइट्स लौटाया।

समस्या यह है कि SSL सर्वर प्रमाणपत्र छूट गया और युगल सर्वर पर स्थापित नहीं किया गया था।


0

यदि आप पहली बार में हैंडशेक स्थापित कर सकते हैं, तो जाँच करने का प्रयास करें। फ़ाइल अपलोड करते समय मेरे पास यह समस्या थी और मुझे केवल यह पता चला था कि जब मैं अपलोड को हटा सकता था और जाँच कर सकता था कि क्या यह पैरामीटर दिए गए मापदंडों को हटा सकता है, तो यह मुद्दा कोई भी नहीं था।


0

एक अन्य विकल्प ट्राइ-कैच ब्लॉक का उपयोग करके उत्पन्न त्रुटि कोड की जांच करना और पहले एक WebException को पकड़ना होगा।

मेरे मामले में, HTTPS url पर सर्टिफिकेट इश्यू के कारण त्रुटि कोड "SendFailure" था, एक बार जब मैंने HTTP को हिट किया, तो वह हल हो गया।

https://docs.microsoft.com/en-us/dotnet/api/system.net.webexceptionstatus?redirectedfrom=MSDN&view=netframework-4.8


0

मेरे लिए, यह एक ऐसा मुद्दा था जहां IIS बाइंडिंग में वेब सर्वर का आईपी पता था। मैंने सभी अनसाइन किए गए IP का उपयोग करने के लिए इसे बदल दिया और मेरे एप्लिकेशन ने काम करना शुरू कर दिया।


0

मैंने एडीएमडी का उपयोग करके Microsoft एनालिटिक सेवाओं के लिए अजगर क्लेर रनिंग mdx क्वेरी के साथ त्रुटि का अनुभव किया

मैंने इसे हंस वॉन की मदद से हल किया और यहाँ अजगर संस्करण है:

clr.AddReference("System.Net")
from System.Net import ServicePointManager, SecurityProtocolType 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls

0

जो लोग इसे बाद में पा सकते हैं। .NET संस्करण 4.6 के बाद, मैं इस समस्या में भी चल रहा था।

सुनिश्चित करें कि आप निम्न पंक्तियों के लिए अपनी web.config फ़ाइल की जाँच करें:

<compilation debug="true" targetFramework="4.5">
...
<httpRuntime targetFramework="4.5" />

यदि आप सर्वर पर 4.6.x या .NET का उच्च संस्करण चला रहे हैं, तो सुनिश्चित करें कि आपने अपने सर्वर पर फ्रेमवर्क के संस्करण से मिलान करने के लिए इन targetFramework मानों को समायोजित किया है। यदि आपके संस्करण 4.6.x से कम पढ़ते हैं, तो मैं आपको .NET को अपग्रेड करने और नए संस्करण का उपयोग करने की सलाह दूंगा जब तक कि आपका कोड पुराने संस्करण पर निर्भर न हो (जो उस स्थिति में, आपको इसे अपडेट करने पर विचार करना चाहिए)।

मैंने लक्ष्यप्रकार को 4.7.2 में बदल दिया और समस्या गायब हो गई:

<compilation debug="true" targetFramework="4.7.2">
...
<httpRuntime targetFramework="4.7.2" />

नए फ्रेमवर्क उपलब्ध सर्वोत्तम प्रोटोकॉल का उपयोग करके और असुरक्षित या अप्रचलित को अवरुद्ध करके इस मुद्दे को सुलझाते हैं। यदि आप जिस रिमोट सेवा से जुड़ने या कॉल करने का प्रयास कर रहे हैं वह यह त्रुटि दे रही है, तो यह हो सकता है कि वे पुराने प्रोटोकॉल का समर्थन न करें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.