Bir sunucu uygulamam var ve bazen istemci bağlanmaya çalıştığında aşağıdaki hatayı alıyorum:
NOT: "İstemciden akış alınamadı veya giriş başarısız oldu" benim tarafımdan catch deyiminde eklenen bir metindir
ve durduğu satır (sThread: satır 96):
tcpClient = (TcpClient)client;
clientStream = tcpClient.GetStream();
sr = new StreamReader(clientStream);
sw = new StreamWriter(clientStream);
// line 96:
a = sr.ReadLine();
Bu soruna ne sebep olabilir? Her zaman olmadığını unutmayın
Yanıtlar:
Bu hata genellikle hedef makinenin çalıştığı, ancak bağlanmaya çalıştığınız hizmetin mevcut olmadığı anlamına gelir. (Ya durdu, çöktü ya da başka bir istekle meşgul.)
Bağlantı: İngilizce makinenin yapıldığı ancak hizmet mevcut değildi çünkü (hizmet çalışır o uzak ana / sunucu / PC) üzerine o makinenin, makine istekle ne yapacağını bilmiyordu.
Makineyle bağlantı mevcut değilse, farklı bir hata görürsünüz. Ne olduğunu unutuyorum, ancak "Hizmete Ulaşılamıyor" veya "Kullanılamıyor" satırlarında.
Düzenle - eklendi
Bunun nedeni bağlantı noktasını engelleyen bir güvenlik duvarından kaynaklanıyor olabilir, ancak aralıklı olduğunu söylediğinize göre ("bazen istemci bağlanmaya çalıştığında"), bu pek olası değildir. Bunu orijinal olarak eklemedim çünkü cevap vermeden önce zihinsel olarak dışlamıştım.
Bir web servisini ararken bu hatayı aldım. Sorun aynı zamanda ulaşım seviyesi güvenliğiyle de ilgiliydi. Web servisini bir web sitesi projesi aracılığıyla arayabilirdim, ancak aynı kodu bir test projesinde yeniden kullanırken bu mesajı içeren bir WebException alıyordum. Aramayı yapmadan önce aşağıdaki satırı eklemek sorunu çözdü:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;Düzenle
System.Net.ServicePointManager.SecurityProtocol - Bu özellik, yalnızca Güvenli Köprü Metni Aktarım Protokolü (HTTPS) şemasını kullanan yeni bağlantılar için kullanılacak Güvenli Yuva Katmanı (SSL) veya Aktarım Katmanı Güvenliği (TLS) protokolünün sürümünü seçer; mevcut bağlantılar değiştirilmez.
SecurityProtocolProtokol sürümünü seçerken TLS anlaşması sırasında yapılandırmanın önemli olduğuna inanıyorum .
TLS el sıkışması - Bu protokol, gerçek uygulama verilerinin TLS ile değişimi için her iki tarafın da ihtiyaç duyduğu tüm bilgileri değiş tokuş etmek için kullanılır.
ClientHello - Bir müşteri, desteklediği en yüksek TLS protokol versiyonunu belirten bir ClientHello mesajı gönderir ...
ServerHello - Sunucu, seçilen protokol sürümünü içeren bir ServerHello mesajı ile yanıt verir ... Seçilen protokol sürümü, hem istemcinin hem de sunucunun desteklediğinden en yüksek olmalıdır. Örneğin, istemci TLS sürüm 1.1'i destekliyorsa ve sunucu sürüm 1.2'yi destekliyorsa, sürüm 1.1 seçilmelidir; sürüm 1.2 seçilmemelidir.
Benim özel durum senaryom, Azure uygulama hizmetinin minimum TLS sürümünün 1.2 olarak değiştirilmesiydi.
Şu andan itibaren bunun varsayılan olup olmadığını bilmiyorum, ancak onu 1.0 olarak değiştirmek işe yaradı.
Ayara "SSL Ayarları" içinden erişebilirsiniz.
Bu blog yayınlarındaki düzeltmelerden hangisinin yardımcı olduğundan emin değilim, ancak bir tanesi bu sorunu benim için sıraladı ...
Bana yardımcı olan hile, bir WebRequest'i kullanmayı bırakmak ve bunun yerine bir HttpWebRequest kullanmaktı. HttpWebRequest 3 önemli ayarla oynamama izin veriyor:
ve
Sunucularımızdan birinden HTTPS hizmetlerine yapılan çağrılar da " Taşıma bağlantısından veri okunamıyor: Mevcut bir bağlantı zorla kapatıldı " istisnasını atıyordu . HTTP hizmeti yine de iyi çalıştı. Bunun bir TLS el sıkışma Hatası olduğunu görmek için Wireshark'ı kullandı. Sunucudaki şifre paketinin güncellenmesi gerektiğinden sona erdi.
"Hans Vonn" yanıtlarına göre.
Aramayı yapmadan önce aşağıdaki satırı eklemek sorunu çözdü:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;Güvenlik protokolünü ekledikten ve iyi çalıştıktan sonra, ancak sağlıklı olmayan her API çağrısından önce eklemem gerekiyor. Sadece .net framework sürümünü en az 4.6 yükseltiyorum ve beklendiği gibi çalışmak her API çağrısından önce eklemeyi gerektirmiyor.
Bu, ara sıra ortaya çıkan sorunlara yardımcı olmaz, ancak benzer bir sorunu olan diğer insanlar için yararlı olabilir.
Bir VM'yi klonladım ve onu yeni bir IP adresiyle farklı bir ağda başlattım ancak IIS'deki bağlantıları değiştirmedim. Fiddler bana "Aktarım bağlantısından veri okunamıyor: Mevcut bir bağlantı uzak ana bilgisayar tarafından zorla kapatıldı" diyordu ve IE bana "Gelişmiş ayarlarda TLS 1.0, TLS 1.1 ve TLS 1.2'yi aç" diyordu. Yeni IP adresine bağlanmayı değiştirmek benim için çözdü.
Bazı nedenlerden dolayı, sunucuyla bağlantı kesildi. Sunucu bağlantıyı açıkça kapatmış olabilir veya sunucudaki bir hata beklenmedik bir şekilde kapatılmasına neden olabilir. Veya istemci ile sunucu (bir anahtar veya yönlendirici) arasındaki bir şey bağlantıyı kesti.
Soruna neden olan sunucu kodu olabilir ve olmayabilir. Sunucu koduna erişiminiz varsa, istemci bağlantılarının ne zaman kapandığını size bildirmek için oraya bazı hata ayıklama işlemleri koyabilirsiniz. Bu size bağlantıların ne zaman ve neden kesildiğine dair bazı ipuçları verebilir.
İstemcide, sunucunun herhangi bir zamanda başarısız olma olasılığını hesaba katmak için kodunuzu yazmanız gerekir. İşte böyle: ağ bağlantıları doğal olarak güvenilmezdir.
Bu benim sorunumu çözdü. Bu satırı istek yapılmadan önce ekledim:
System.Net.ServicePointManager.Expect100Continue = false;Sunucu yolunda 100 devam etme davranışını desteklemeyen bir proxy var gibi görünüyordu.
Bu sorunu geçmişte yaşadım. PostgreSQL kullanıyorum ve programımı çalıştırdığımda bazen bağlanıyor bazen de böyle bir hata veriyor.
Kodumu denediğimde, Bağlantı kodumu genel Formun altındaki ilk satıra koyuyorum. İşte bir örnek:
ÖNCE:
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());
}ŞİMDİ:
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!
}Herhangi bir şey yapmadan önce programın önce bağlantıyı okuması gerektiğini düşünüyorum, bilmiyorum, yanılıyorsam düzeltin. Ama araştırmama göre, bu bir kod problemi değil - aslında makinenin kendisindendi.
Mutlu Kodlama!
System.Net.ServicePointManager.Expect100Continue = false;Bu sorun bazen web sunucusunda proxy sunucusunun uygulanması nedeniyle ortaya çıkar. Gönderme servisini aramadan önce bu satırı koyarak proxy sunucusunu atlamak için.
Gönderilen istekleri denemek ve görmek için çalışan bir Üçüncü Taraf uygulaması (Fiddler) vardı. Bu uygulamayı kapatmak benim için sorunu çözdü
Bir müşterinin web sitesinin Web API hizmetimize bağlanmaya çalıştığı ve aynı mesajı aldığı çok benzer bir sorun yaşadık. Bu, IIS'nin çalıştığı sunucuda herhangi bir kod değişikliği veya Windows güncellemesi olmadığında tamamen birdenbire olmaya başladı.
Bizim durumumuzda, arayan web sitesinin yalnızca TLS 1.0'ı destekleyen bir .Net sürümünü kullandığı ve bazı nedenlerden dolayı IIS'imizin çalışmadığı sunucunun TLS 1.0 çağrılarını kabul etmeyi durdurduğu ortaya çıktı. IIS sunucusundaki kayıt defteri aracılığıyla TLS'yi açıkça etkinleştirmemiz ve ardından bu sunucuyu yeniden başlatmamız gerektiğini teşhis etmek için. Reg anahtarları şunlardır:
[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:00000001Buradaki başka bir soruya cevabım , girişleri eklemek için kullandığımız bu powershell betiğine sahip:
NOT: Eski güvenlik protokollerini etkinleştirmek iyi bir fikir değildir, bizim durumumuzda doğru cevap, müşteri web sitesinin kodunu TLS 1.2 kullanacak şekilde güncellemektir, ancak yukarıdaki kayıt defteri girişleri ilk etapta sorunu teşhis etmeye yardımcı olabilir.
Bunun benim başıma gelmesinin nedeni, DI sağlayıcımda yinelemeli bir bağımlılık olmasıydı. Benim durumumda:
services.AddScoped(provider => new CfDbContext(builder.Options));
services.AddScoped(provider => provider.GetService<CfDbContext>());Düzeltme, yalnızca ikinci kapsamlı hizmet kaydını kaldırmaktı
services.AddScoped(provider => new CfDbContext(builder.Options));Etki alanında bir https sertifikanız varsa, IIS'deki etki alanı adına https bağlaması yaptığınızdan emin olun. IIS'de -> Alanınızı seçin -> Bağlantılar'a tıklayın Site Bağlamaları Penceresi açılır. Https için bir bağlama ekleyin.
Benzer bir sorunla karşılaştım ve hangi uygulamayı kullandığıma ve güvenlik duvarı / yük dengeleyiciyi atlayıp atlamadığımıza bağlı olarak aşağıdaki hataları alıyordum:
HTTPS anlaşması [blah] (# 136 için) başarısız oldu. System.IO.IOException Aktarım bağlantısından veri okunamıyor: Mevcut bir bağlantı uzak ana bilgisayar tarafından zorla kapatıldı
ve
ReadResponse () başarısız oldu: Sunucu bu istek için tam bir yanıt vermedi. Sunucu 0 bayt döndürdü.
Sorun, SSL Sunucu Sertifikasının kaçırılması ve birkaç sunucuya yüklenmemiş olmasıydı.
Başka bir seçenek, dene-yakala bloğu kullanılarak üretilen hata kodunu kontrol etmek ve önce bir WebException'ı yakalamaktır.
Benim durumumda, HTTP'ye tıkladığımda çözülen HTTPS url'deki sertifika sorunu nedeniyle hata kodu "SendFailure" idi.
Benim için, IIS bağlamasında web sunucusunun IP adresine sahip olduğu bir sorundu. Atanmamış tüm IP'leri kullanacak şekilde değiştirdim ve uygulamam çalışmaya başladı.
Adomd kullanarak Microsoft analitik hizmetlerine mdx sorgusu çalıştıran python clr hatasıyla karşılaştım
Bunu Hans Vonn'un yardımıyla çözdüm ve işte python versiyonu:
clr.AddReference("System.Net")
from System.Net import ServicePointManager, SecurityProtocolType
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.TlsBunu daha sonra bulabilenler için, .NET 4.6 sürümünden sonra, ben de bu sorunla karşılaşıyordum.
Aşağıdaki satırlar için web.config dosyanızı kontrol ettiğinizden emin olun:
<compilation debug="true" targetFramework="4.5">
...
<httpRuntime targetFramework="4.5" />Sunucuda 4.6.x veya daha yüksek bir .NET sürümünü çalıştırıyorsanız, bu targetFramework değerlerini sunucunuzdaki çerçeve sürümüyle eşleşecek şekilde ayarladığınızdan emin olun. Sürümleriniz 4.6.x'ten daha az okursa, kodunuz eski bir sürüme bağlı değilse (bu durumda güncellemeyi düşünmelisiniz) .NET'i yükseltmenizi ve daha yeni sürümü kullanmanızı öneririm.
TargetFrameworks'ü 4.7.2 olarak değiştirdim ve sorun ortadan kalktı:
<compilation debug="true" targetFramework="4.7.2">
...
<httpRuntime targetFramework="4.7.2" />Yeni çerçeveler, mevcut en iyi protokolü kullanarak ve güvensiz veya eski olanları engelleyerek bu sorunu çözer. Bağlanmaya çalıştığınız veya aramaya çalıştığınız uzak hizmet bu hatayı veriyorsa, eski protokolleri artık desteklemiyor olabilirler.