একটি বিদ্যমান সংযোগ জোর করে দূরবর্তী হোস্ট দ্বারা বন্ধ করা হয়েছিল

158

আমি একটি বাণিজ্যিক অ্যাপ্লিকেশন নিয়ে কাজ করছি যা বার্তাটির সাথে সকেট এক্সসেপশন নিক্ষেপ করছে,

একটি বিদ্যমান সংযোগ জোর করে দূরবর্তী হোস্ট দ্বারা বন্ধ করা হয়েছিল

এটি ক্লায়েন্ট এবং সার্ভারের মধ্যে একটি সকেট সংযোগের সাথে ঘটে। সংযোগটি জীবিত এবং ভাল, এবং ডেটার হিপগুলি স্থানান্তরিত হচ্ছে, তবে এটি কোথাও থেকে সংযোগ বিচ্ছিন্ন হয়ে যায়।

এর আগে কি কেউ দেখেছেন? কারণগুলি কী হতে পারে? আমি কয়েকটি কারণ অনুমান করতে পারি, তবে কারণ কী হতে পারে তা কাজ করার জন্য এই কোডটিতে আরও যুক্ত করার কোনও উপায় আছে কি?

কোন মন্তব্য / ধারণা স্বাগত।

... সাম্প্রতিক ...

আমার কিছু নেট। ট্রেসিং থেকে লগইন হয়েছে,

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 এর অর্থ শূন্য বাইটের একটি প্যাকেট প্রেরণের চেষ্টা করা হচ্ছে।

আপনি কি শ্রেণীভুক্ত না? আমার ধারণা এটি অনির্বাচিত হতে পারে তবে সম্ভবত অন্য কেউ এই ধরণের জিনিস দেখেছেন?

c# .net networking sockets

— পিটার
সূত্র

শুধু একটি আপডেট। দেখে মনে হচ্ছে আমাদের নেটওয়ার্ক সেটআপের কারণে ওয়্যারশার্ক এ ক্ষেত্রে এটি কাটবে না। তবে আমি আশা করি এটি চেষ্টা করতে যাচ্ছি। ব্লগস.এমএসডন.ড.কম / ডিগ্রিটি / অর্চিভ / ২০০৫/০৯/১18 / ১৮71৪০০০০৩.aspx যা। নেট ব্যবহার করে ট্রেস করছে যা কিছু লগ ফাইল তৈরি করবে should আমি আপনাকে পোস্ট রাখব ...

— পিটার

1

কমকাস্টে জাল আইডি দিয়ে

98

এর অর্থ সাধারণত যে দূরবর্তী পক্ষটি সংযোগটি বন্ধ করে দেয় (সাধারণত টিসিপি / আইপি RSTপ্যাকেট প্রেরণ করে )। আপনি যদি কোনও তৃতীয় পক্ষের অ্যাপ্লিকেশন নিয়ে কাজ করছেন তবে সম্ভাব্য কারণগুলি হ'ল:

আপনি অ্যাপ্লিকেশনটিতে ত্রুটিযুক্ত ডেটা প্রেরণ করছেন (যার মধ্যে একটি HTTP সার্ভারে HTTPS অনুরোধ প্রেরণ অন্তর্ভুক্ত থাকতে পারে)
ক্লায়েন্ট এবং সার্ভারের মধ্যে নেটওয়ার্ক লিঙ্কটি কোনও কারণে নীচে নেমে যাচ্ছে
আপনি তৃতীয় পক্ষের অ্যাপ্লিকেশনটিতে একটি বাগ ট্রিগার করেছেন যা এটি ক্রাশ করে
তৃতীয় পক্ষের অ্যাপ্লিকেশনটিতে সিস্টেমের সংস্থান শেষ হয়ে গেছে

এটি সম্ভবত প্রথম ঘটনা যা ঘটছে তা সম্ভবত।

সমস্যাটি সঙ্কুচিত করতে তারে ঠিক কী ঘটছে তা দেখতে আপনি ওয়্যারশার্ককে জ্বালিয়ে দিতে পারেন।

আরও সুনির্দিষ্ট তথ্য ব্যতীত, এখানকার যে কেউ সত্যিই আপনাকে অনেক বেশি সাহায্য করতে পারে এমন সম্ভাবনা কম।

— RarrRarrRarr
সূত্র

2

গ্রেট। ধন্যবাদ। ওয়্যারশার্ক সম্পর্কে অন্য জিনিস। এটি এত বেশি ডেটা সংগ্রহ করে, আমি কীভাবে এইরকম কিছু ফিল্টার করতে সক্ষম হব? যদি ওয়্যারশার্ক কিছু দেখায় তবে আমি এটি পরে পোস্ট করতে পারি ...

— পিটার

4

আপনার অন্তত আইপি ঠিকানা এবং পোর্ট নম্বর দ্বারা ওয়্যারশার্ক ডাম্প ফিল্টার করতে সক্ষম হওয়া উচিত। এরপরে, স্ট্রিমের শেষ দিকে (যেখানে কিছু ভুল হয়েছে) দেখুন এবং যেদিকে জিনিসগুলি প্রথমে গোলমাল হয়ে যায় তা স্পষ্ট না করা পর্যন্ত পিছনে কাজ করা সম্ভবত সবচেয়ে সহায়ক। জড়িত প্রোটোকলের জটিলতার উপর নির্ভর করে এটি প্রায় অসম্ভবের পক্ষে সত্যিই সহজ হতে পারে ...

— RarrRarrRarr

4

বুলেটযুক্ত আইটেমগুলির জন্য কোনও উত্স আছে, বা নীচে গেমারের উত্তরটি আপনার তালিকাটি অনুলিপি করেছে?

— জ্যাক

7

দয়া করে নোট করুন যে "ত্রুটিযুক্ত ডেটা প্রেরণ" এর অর্থ সার্ভারে একটি httpsঅনুরোধ প্রেরণ httpএবং সম্ভবত বিপরীত হতে পারে।

— এক্সএমআইএম

2

আমার ক্ষেত্রে, আমি স্থানীয়ভাবে অ্যাপ্লিকেশন চালানোর সময় কেবল কোনও এপি কল করার সময় এই ব্যতিক্রম পাচ্ছিলাম। ডিভ, কিএ, বা প্রোড পরিবেশে কোনও সমস্যা নেই। ঠিক করা? স্থানীয়ভাবে https এর পরিবর্তে HTTP ব্যবহার করা। আমরা মনে করি এটি কোনও লোড ব্যালেন্সারের সাথে সম্পর্কিত হতে পারে। তবে আমরা কেবলমাত্র https- র রূপান্তর সহ আমাদের ডেভ, কিউ এবং প্রো ওয়েব ওয়েবকনফিগগুলি আপডেট করেছি। সমস্যা সমাধান.

— কার্শা

82

টিএলএস 1.2 ব্যবহার করে এই ত্রুটিটি সমাধান হয়েছে।
আপনি এটির সাহায্যে টিএলএস 1.2 ব্যবহার করে আপনার অ্যাপ্লিকেশনটিকে জোর করতে পারেন (আপনার পরিষেবাটি কল করার আগে এটি কার্যকর করা নিশ্চিত করুন):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

অন্য সমাধান:
TLS1.2 ব্যবহার করার জন্য আপনার স্থানীয় মেশিন বা সার্ভারে শক্তিশালী ক্রিপ্টোগ্রাফি সক্ষম করুন কারণ ডিফল্টরূপে এটি অক্ষম থাকে তাই কেবলমাত্র টিএলএস 1.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

এই পরিবর্তনগুলি কার্যকর করতে আপনার কম্পিউটার পুনরায় বুট করতে হবে।

— willmaz
সূত্র

1

একাধিক প্রোটোকল সমর্থন করতে আপনি একসাথে একাধিক মান যুক্ত করতে পারেন। সুতরাং এসএসএল 3 থেকে টিএলএস 1.2 পর্যন্ত সমস্ত কিছু সমর্থন করার জন্য, সুরক্ষাপ্রোটোকল = (সিকিউরিটিপ্রোটোকল টাইপ) 4080 সেট করুন।

— অ্যাবাকাস

29

এটি আপনার কোডে কোনও বাগ নয়। এটি নেট। সকেট বাস্তবায়ন থেকে আসছে। আপনি নীচে হিসাবে এন্ডরিসিভের ওভারলোডেড বাস্তবায়নটি ব্যবহার করলে আপনি এই ব্যতিক্রমটি পাবেন না।

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

— cagatay
সূত্র

1

এটি অপারেটিং সিস্টেম থেকে এবং শেষ পর্যন্ত পিয়ারের কাছ থেকে আসছে। এটি আরও একটি ব্যাখ্যা যে এটি একটি সফ্টওয়্যার বাগ।

— মারকুইস অফ লর্ন

5

+1 টি। আমার সি # প্রোগ্রামে, আমি EndReceiveযখন কৃপণ ক্লায়েন্টের অবসান ঘটে তখন কেন একটি ব্যতিক্রম ছুঁড়ে ফেলা হচ্ছে তা নিয়ে আমি মাথা ঘুরছিলাম। জানেন না এটি ডিজাইনের মাধ্যমে। আমি স্বাভাবিক কোড প্রবাহে ব্যতিক্রম ছুঁড়ে ফেলার এটির খারাপ নকশা অনুভব করি। অতিরিক্ত লোড পদ্ধতির জন্য Godশ্বরের ধন্যবাদ।

— পবন মঞ্জুনাথ

2

@ এমএসডি এটি একটি অ্যাসিঙ্ক্রোনাস কল ব্যবহার করছে, নিশ্চিত হয়ে নিন যে আপনি ডেটা ফেরত দেওয়ার প্রক্রিয়া করার সময় আপনার কোডটি থামবে না। উদাহরণগুলি এমএসডিএন.মাইক্রোসফট /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

2

@ কেগাটে এটি সমাধান দেওয়ার সময় আমি কখনও অ্যাসিক্রোনাস পদ্ধতিতে মূল্য দেখিনি যেখানে আপনি Sendঅন্য কিছু করার আগে আপনার কাজ করার পরে কী ফিরে আসছে তা অবিলম্বে আপনাকে জানতে হবে।

— vapcguy

3

আসলে আমি আবিষ্কার করেছি যে এই পদ্ধতিটি নির্বোধ নয়। : এটা এছাড়াও ওপি এর ত্রুটি সৃষ্টি করতে পারে stackoverflow.com/questions/17790612/...

— vapcguy

10

এই সাধারণ বিরক্তিকর সমস্যার সহজ সমাধান:

কেবলমাত্র আপনার " .context.cs" ফাইলটিতে যান (" .context.tt" এর নীচে অবস্থিত যা আপনার "* .edmx" ফাইলের অধীনে রয়েছে)।

তারপরে আপনার কনস্ট্রাক্টরে এই লাইনটি যুক্ত করুন:

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

আশা করি এটি সহায়ক।

— ayheber
সূত্র

@ এসি কোথায় রাখবেন? এবং কোনও রিটার্নের ধরণ নেই ??

— খলিল খালাফ

2

@ ফার্স্টস্টেপ: কোজ এটি একটি নির্মাণকারী।

— নিখিল আগরওয়াল

3

এটি কেবলমাত্র এন্টি ফ্রেমওয়ার্ক ব্যবহার করে যারা সমস্যাটি অনুভব করছে তাদেরকে সহায়তা করে, যারা socket.Send(x); byte[] buffer = new byte[1]; socket.Receive(buffer, 0, 1, 0);ফিরে আসা বাইটগুলি পড়ার জন্য সরল কাজ করে না , যা ওপি'র সমস্যা ছিল।

— ভ্যাপকুই

ENTITY FRAMEWORKশুধুমাত্র এই সমাধান ব্যবহার করে যদি !!! শুধুমাত্র এই ! ধন্যবাদ ভাই :)

— রাও হামাস 25'19

9

একই বাগ ছিল। আসলে ট্র্যাফিক কিছু প্রক্সি ব্যবহার করে প্রেরণ করা হয়েছিল (আমার ক্ষেত্রে fiddler) যদি কাজ করে। নেট ফ্রেমওয়ার্কটি 4.5.2 থেকে> = 4.6 পর্যন্ত আপডেট হয়েছে এবং এখন সবকিছু ঠিকঠাক কাজ করে। আসল অনুরোধটি ছিল:
new WebClient().DownloadData("URL");
ব্যতিক্রমটি ছিল:

সকেটএক্সেপশন: একটি বিদ্যমান সংযোগ জোর করে দূরবর্তী হোস্ট দ্বারা বন্ধ করা হয়েছিল

— 0x49D1
সূত্র

5

আমার জন্য জিনিসগুলি সমাধান করার এটি ছিল এক উপায়। এটি আসলে টিএলএস .NET এর কোন সংস্করণ ডিফল্টরূপে ব্যবহৃত হয়েছিল তার সাথে সম্পর্কিত। ৪.৪.২ এবং নিম্ন ব্যবহৃত টিএলএস ১.০ ব্যবহার করে, যখন ৪.6 এবং তার চেয়ে বেশি সংখ্যক 1.1 এবং 1.2 ব্যবহারের বিষয়ে স্মার্ট। এটি সার্ভারে টিএলএস প্রয়োজনীয়তা ১.০ এ ফেলে দিয়ে প্রমাণযোগ্যও হয়েছিল, যা সমস্যাটিও স্থির করে।

— হটএন

4

সত্তার মধ্যে বিজ্ঞপ্তি রেফারেন্সের কারণে আমি এই ব্যতিক্রম পেয়েছি entity

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] যুক্ত করেছি। এবং এটি সমস্যার সমাধান।

— বাজালিভ নিকোলায়
সূত্র

2

যদি এ। নেট 4.5.৪.২ পরিষেবা চালিত হয়

আমার জন্য সমস্যাটি আরও জটিল হয়েছিল কারণ কলটি একটি নেট .৪.৪.২ পরিষেবাতে চলছিল। আমি @ উইলমজ পরামর্শটি অনুসরণ করেছি তবে একটি নতুন ত্রুটি পেয়েছি।

লগিং চালু রেখে সার্ভিসটি চালানোর সময়, আমি লক্ষ্য করেছি যে টার্গেট সাইটের সাথে হ্যান্ডশেকিং ঠিক আছে (এবং বহনকারী টোকেন প্রেরণ করবে) তবে পোস্ট কলটি প্রক্রিয়া করার জন্য নিম্নলিখিত পদক্ষেপে, এটি অটোথ টোকনকে ছাড়বে এবং সাইটটি জানিয়ে উত্তর Unauthorized।

দেখা গেল যে সার্ভিস পুলের শংসাপত্রগুলিতে টিএলএস (?) পরিবর্তন করার অধিকার নেই এবং যখন আমি আমার স্থানীয় অ্যাডমিন অ্যাকাউন্টটি পুলটিতে রাখি তখন এটি সব কাজ করে।

— ΩmegaMan
সূত্র

2

স্ট্রিম থেকে ডেটা পড়ার সময় যে কেউ এই ব্যতিক্রম পাচ্ছেন তাদের পক্ষে এটি সহায়তা করতে পারে। এই জাতীয় লুপে এইচটিপিআরস্পোনসেসেজটি পড়ার সময় আমি এই ব্যতিক্রম পাচ্ছিলাম:

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);
}

কপিটো () পদ্ধতির ডিফল্ট বাফার আকার 81920। রয়েছে buff তবে এই ত্রুটি রোধে গতির বিষয়টি ডাউনলোড করবে কেন?

এটি সম্ভবত সার্ভার থেকে সংযোগ বিচ্ছিন্ন হয়ে পড়েছে কারণ ডাউনলোডের গতি সর্বনিম্ন প্রান্তিকের নীচে নেমে যাবার জন্য সার্ভারটি কনফিগার করা হয়েছে। উদাহরণস্বরূপ, আপনি যে অ্যাপ্লিকেশন থেকে ফাইলটি ডাউনলোড করছেন সেটি আইআইএস-এ হোস্ট করা থাকলে, এটি http.sys কনফিগারেশনে সমস্যা হতে পারে:

"এইচটিটিপি.সাইস হ'ল এইচটিপি প্রোটোকল স্ট্যাক যা আইআইএস ক্লায়েন্টদের সাথে HTTP যোগাযোগ সম্পাদন করতে ব্যবহার করে Min 240 কেবি / সেকেন্ডে সেট করুন। "

টিএফএস ডেভলপমেন্ট টিমের এই পুরাতন ব্লগপোস্টে সমস্যাটি বর্ণিত হয়েছে এবং আইআইএসকে বিশেষভাবে উদ্বেগ জানিয়েছে তবে আপনাকে সঠিক দিক নির্দেশ করতে পারে। এটি এই http.sys বৈশিষ্ট্য: লিঙ্ক সম্পর্কিত একটি পুরানো বাগ উল্লেখ করেছে

আপনি যদি অ্যাজুরি অ্যাপ্লিকেশন পরিষেবা ব্যবহার করছেন এবং বাফারের আকার বৃদ্ধি করা সমস্যাটি দূর করে না, আপনার মেশিনটিও স্কেল করার চেষ্টা করুন। আপনাকে সংযোগ ব্যান্ডউইথ সহ আরও সংস্থানগুলি বরাদ্দ করা হবে।

— আন্দ্রেজ লুকানস্কি
সূত্র

0

আমি একই সমস্যা ছিল এবং অবশেষে এটি সমাধান করতে পরিচালিত। আমার ক্ষেত্রে, ক্লায়েন্টটি যে পোর্টটির জন্য অনুরোধ প্রেরণ করে তার কোনও এসএসএল শংসাপত্র বাধ্যতামূলক নেই। সুতরাং আমি সার্ভারের পাশের বন্দরে একটি এসএসএল সার্টিটি বেঁধে দিয়ে সমস্যার সমাধান করেছি। একবার এটি হয়ে গেলে, এই ব্যতিক্রমটি চলে যায়।

— iefgnoix
সূত্র

-1

এই ত্রুটিটি সিআইপি-প্রোটোকলের সাথে আমার অ্যাপ্লিকেশনটিতে দেখা গেছে যখনই আমি 10 এরও কম সময়ে ডেটা প্রেরণ করি না বা পাইনি received

এটি ফরওয়ার্ড ওপেন পদ্ধতি ব্যবহারের কারণে ঘটেছিল। আপনি অন্য কোনও পদ্ধতির সাথে কাজ করে এড়াতে পারবেন বা আপনার ফরোয়ার্ড-ওপেন-সংযোগ বজায় রাখার জন্য 10 এর কমের একটি আপডেটের হার ইনস্টল করতে পারেন।

— Belekz
সূত্র