We Keep Coding

HTTP 1.1 protocol read-line error from server

I am sending a message to a server through HTTP 1.1. Everything sends correctly to the server or website I have chosen, but when I receive the response from the server/website and my sr.readToEnd() executes, it terminates.
I know that the message I have sent is correct, but I am trying to do a try-catch statement were if it terminates again, it will try to read another way. I am not sure how to do this and I was advised that I could use content-length (except I do not know how to do that either).
Here is what I have so far:
try
{ //Read server message
String response = sr.ReadToEnd();
}
catch
{ //If terminate occurs, read a different way
}
If I remove the try/catch blocks I see this:
Unhandled Exception: System.IO.IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time..
I know it's pretty brief what I provided, but any methods to tackle this sort of problem I described?

I'd say in general you can do (as #joel recommended.
Or try whether catch when() works for you.
Example:
try
{
someCode();
}
catch (YourExpectedException ex) when (
someBooleanExpression
|| someOtherBooleanExpr
|| thirdBoolean)
{
/* this part runs when() YourExpectedException occurs *and*
one of those three hypothetical example expressions is True */
}
catch (YourExpectedException ex)
{
/* this part runs If YourExpectedException occurs and the previous
When() expression is *Not true */
Whatever();
} /* you can continue catching other expected exceptions
and when() combinations here.
And/Or perhaps say any other exception is unexpected and
will be handled by a higher-level:
*/
catch // any other Exception just to re-throw it back 'to-whom-it-may-concern':
throw;
See also Catching exceptions with "catch, when"

How do I catch Revit errors in Revit API?

I'm trying to catch an error displayed in Revit to perform some handle operations. Error is due to the connection of points as shown in the image below.
Error image
This is what I have tested with so far.
try
{
var pipe = Pipe.Create(doc, firstPipeType.Id, level.Id, startCon,
pathXyz[0]);
}
catch (Autodesk.Revit.Exceptions.InvalidOperationException e)
{
message = e.Message;
return Result. Failed;
}
Based on the documentation, I am trying to catch and handle the following exception.
"Autodesk.Revit.Exceptions.InvalidOperationException: Thrown when the new pipe fails to connect with the connector."

The error message is different from the exception. The instructions on how to handle the error message are provided by The Building Coder in the topic group on Detecting and Handling Dialogues and Failures.

Wi-Fi Direct UWP timeouts (Exception from HRESULT: 0x800705B4)

I'm starting a Wi-Fi Direct access point service using the UWP APIs. It starts OK. I'm using WiFiDirectConnectionListener to monitor for devices that get connected to the access point using the ConnectionRequested event.
var connectionRequest = args.GetConnectionRequest();
var deviceInformation = connectionRequest.DeviceInformation;
// FromIdAsync needs to be called from the UI thread (in MS example).
var isConnected = RunOnUIThreadAsync(() =>
{
try
{
var device = WiFiDirectDevice.FromIdAsync(deviceInformation.Id).AsTask().Result;
if (device != null)
{
device.ConnectionStatusChanged -= OnDeviceConnectionStatusChanged;
device.ConnectionStatusChanged += OnDeviceConnectionStatusChanged;
return true;
}
return false;
}
catch (Exception e)
{
// This throws an Exception from HRESULT: 0x800705B4.
return false;
}
}).Result;
On some devices that get connected to the access point, an exception is thrown on calling FromIdAsync with
This operation returned because the timeout period expired. (Exception from HRESULT: 0x800705B4).
In turn, the device that tries to the access point will not connect.
It's always the same devices that are unable to connect, while others connect just fine. I've tried with and without UI thread but the result remains the same. Am I using this wrong, or is this a bug in Wi-Fi Direct? If so, is there another way to start a Wi-Fi Direct access point without the UWP APIs? Perhaps that's working better.

The workaround to prevent timeout is to have DHCP activated on the client side. I have had this error when trying to connect devices with fixed IP address to the hotspot.

ObjectDisposedException for TCPClient.Close in System.dll?

Im using a Request System called xNet and it seems ObjectDisposedExceptions are occuring which on-occurence causes a HUGE cpu spike, sometimes continuously keeping CPU at 99-100% causing freezes and lag.
The script mentioned is the following:
https://github.com/PR4GM4/xNet-Ameliorated
An example code is:
using (HttpRequest httpRequest = new HttpRequest()) {
string url = "https://httpbin.org";
string[] proxysplit = proxy.Split(':');
httpRequest.Proxy = new InternalProxyClient(ProxyType.HTTP, proxysplit[0], int.Parse(proxysplit[1]), null, null);
httpRequest.UserAgent = Http.ChromeUserAgent();
httpRequest.KeepAlive = true;
httpRequest.ConnectTimeout = 15000;
httpRequest.AllowAutoRedirect = true;
HttpResponse hr = httpRequest.Start(HttpMethod.GET, new Uri(url, UriKind.Absolute), new StringContent(""));
if (hr == null) return "2";
string sr = hr.ToString();
if (sr == null) return "2";
}
(If a list of half/dead proxies are needed, I can provide it, just im not sure if linking to them is allowed or not.)
Big note here, it seems to only ever occur whenever theres some kind of other exception like failing to connect to the proxy, or a general bad response, so good connection proxies and/or no proxy at all never has this issue (unless again a general failed error).
If you loop this code, and give it a dead proxy (And to speed things up, multi-thread it to around 5 a time) it will eventually cause an exception like bad response or a timeout and eventually an objectdisposedexception.
I tried debugging in Visual Studio but it gives me almost no information, Historical Debugging gives no information just "Source not found".
Call Stack for the First Exception Thrown of the ObjectDisposedException in the screenshot above.
Seems to be related to line 1430 in ~Http/HttpRequest.cs or line 217 in ~Proxy/ProxyClient.cs as it's the only line I know to exist thats to do with EndConnect socket and also coincidentally can produce ObjectDisposedException. Just not sure how to properly handle the exception here without causing the rest of the script to fail. Also why does a simple exception here cause so much CPU spike?
Strangely enough, no matter how I wrap an exception handler for ObjectDisposedException it never gets triggered, no matter how much code or where I wrap? (On both scripts)
try
{
tcpClient.EndConnect(ar);
}
catch (Exception ex)
{
connectException = ex;
}

I found out why, it wasnt because of the .EndConnect on either of the 2 files, it was actually caused by the .Close() calls, since it does .EndConnect inside of that, thats why I couldnt see any "Source" etc.
So it was causeed because the socket connection wasnt connected, so doing .Close() would cause the Exception.
It was a simple fix.
(Where tcp = a TcpClient)
Do the following instead of just tcp.Close()
On Timeouts (Where it's most likely if never at all connected):
if (tcp.Client.Connected) {
tcp.GetStream().Close();
tcp.Close();
}
When it might be properly connected:
if (!tcp.Connected) {
if (tcp.Client.Connected) tcp.GetStream().Close();
tcp.Close();
}

The I/O operation has been aborted because of either a thread exit or an application request

My application is working as a client application for a bank server. The application is sending a request and getting a response from the bank. This application is normally working fine, but sometimes
The I/O operation has been aborted because of either a thread exit or
an application request
error with error code as 995 comes through.
public void OnDataReceived(IAsyncResult asyn)
{
BLCommonFunctions.WriteLogger(0, "In :- OnDataReceived",
ref swReceivedLogWriter, strLogPath, 0);
try
{
SocketPacket theSockId = (SocketPacket)asyn.AsyncState;
int iRx = theSockId.thisSocket.EndReceive(asyn); //Here error is coming
string strHEX = BLCommonFunctions.ByteArrToHex(theSockId.dataBuffer);
}
}
Once this error starts to come for all transactions after that same error begin to appear, so
please help me to sort out this problem. If possible then with some sample code
Regards,
Ashish Khandelwal

995 is an error reported by the IO Completion Port. The error comes since you try to continue read from the socket when it has most likely been closed.
Receiving 0 bytes from EndRecieve means that the socket has been closed, as does most exceptions that EndRecieve will throw.
You need to start dealing with those situations.
Never ever ignore exceptions, they are thrown for a reason.
Update
There is nothing that says that the server does anything wrong. A connection can be lost for a lot of reasons such as idle connection being closed by a switch/router/firewall, shaky network, bad cables etc.
What I'm saying is that you MUST handle disconnections. The proper way of doing so is to dispose the socket and try to connect a new one at certain intervals.
As for the receive callback a more proper way of handling it is something like this (semi pseudo code):
public void OnDataReceived(IAsyncResult asyn)
{
BLCommonFunctions.WriteLogger(0, "In :- OnDataReceived", ref swReceivedLogWriter, strLogPath, 0);
try
{
SocketPacket client = (SocketPacket)asyn.AsyncState;
int bytesReceived = client.thisSocket.EndReceive(asyn); //Here error is coming
if (bytesReceived == 0)
{
HandleDisconnect(client);
return;
}
}
catch (Exception err)
{
HandleDisconnect(client);
}
try
{
string strHEX = BLCommonFunctions.ByteArrToHex(theSockId.dataBuffer);
//do your handling here
}
catch (Exception err)
{
// Your logic threw an exception. handle it accordinhly
}
try
{
client.thisSocket.BeginRecieve(.. all parameters ..);
}
catch (Exception err)
{
HandleDisconnect(client);
}
}
the reason to why I'm using three catch blocks is simply because the logic for the middle one is different from the other two. Exceptions from BeginReceive/EndReceive usually indicates socket disconnection while exceptions from your logic should not stop the socket receiving.

In my case, the request was getting timed out. So all you need to do is to increase the time out while creating the HttpClient.
HttpClient client = new HttpClient();
client.Timeout = TimeSpan.FromMinutes(5);

I had the same issue with RS232 communication. The reason, is that your program executes much faster than the comport (or slow serial communication).
To fix it, I had to check if the IAsyncResult.IsCompleted==true. If not completed, then IAsyncResult.AsyncWaitHandle.WaitOne()
Like this :
Stream s = this.GetStream();
IAsyncResult ar = s.BeginWrite(data, 0, data.Length, SendAsync, state);
if (!ar.IsCompleted)
ar.AsyncWaitHandle.WaitOne();
Most of the time, ar.IsCompleted will be true.

I had this problem. I think that it was caused by the socket getting opened and no data arriving within a short time after the open. I was reading from a serial to ethernet box called a Devicemaster. I changed the Devicemaster port setting from "connect always" to "connect on data" and the problem disappeared. I have great respect for Hans Passant but I do not agree that this is an error code that you can easily solve by scrutinizing code.

In my case the issue was caused by the fact that starting from .NET 5 or 6 you must either call async methods for async stream, or sync methods for sync strem.
So that if I called FlushAsync I must have get context using GetContextAsync

What I do when it happens is Disable the COM port into the Device Manager and Enable it again.
It stop the communications with another program or thread and become free for you.
I hope this works for you. Regards.

I ran into this error while using Entity Framework Core with Azure Sql Server running in Debug mode in Visual Studio. I figured out that it is an exception, but not a problem. EF is written to handle this exception gracefully and complete the work. I had VS set to break on all exceptions, so it did. Once I unchecked the check box in VS to not break on this exception, my C# code, calling EF, using Azure Sql worked every time.