RDP, An existing connection was forcibly closed by the remote host

Hello,
I have an RDP (RDPv1) based C# (LSEG.Data v. 2.1.0) application that randomly gets "existing connection was forcibly closed by the remote host" on endpoint requests (like Fundamentals, but not exclusively). See the attached trace in the 2 small extraction files.

1. What is a possible cause of this?
2. Why the session event handlers do not work on "forcibly closed"?
The session is obtained through:
return PlatformSession.Definition(SessionName).AppKey(credentials_?.RDPAppKey)
.OAuthGrantType(new GrantPassword().UserName(credentials_?.RDPUser)
.Password(credentials_?.RDPPassword))
.TakeSignonControl(TakeExclusiveSignonControl.GetValueOrDefault())
.GetSession().OnState((state, msg, s) => SessionStateChanged(state, msg, s))
.OnEvent((eventCode, msg, s) => SessionEventReceived(eventCode, msg, s));

where TakeExclusiveSignonControl is usually False,

As seen, I have the OnState() and OnEvent() handlers installed, but they are not called
when "existing connection was forcibly closed by the remote host" happen.
How to intercept this event when the normal session event handlers do not work?

Thanks
P.Zalewski

forcibly_closed_by_remote_host1.txt

forcibly_closed_by_remote_host2.txt

Find more posts tagged with

rdp

#technology

platform session

Accepted answers

All comments

wasin.w V3

Hello @PatrickZ

The error message "existing connection was forcibly closed by the remote host" indicates that the connection was cut by the server side.

Could you please enable the library log as follows?

Log.Level = NLog.LogLevel.Debug;

By the way, can the application re-request data after got this exception (you may need to catch it in the code)?

PatrickZ

https://community.developers.refinitiv.com/discussion/comment/127685#Comment_127685

Hello
Thank you for your answer.

Well, it is obvious that the connection was reset by the server application. This implies the following questions:
1. Why or in which circumstances this can happen. I can provide the credentials (Machine ID) used by our application at the client site, as well as the timestamps of the events.

2. Why this kind of event is not handled through the LSEG.Data.Core.ISession through the callbacks like OnState() or OnEvent() ? The client application should have a chance to intercept the change of session status and be able to renew the connection. It seems that after "An existing connection was forcibly closed by the remote host" exception the session state is still Opened, while the connection is in reality broken.

3. It is not really possible to catch the exception because it can happen anywhere, so it can be caught in the application Main() which, in the case of the event driven applications, does not have the access to the Session reference. In our case, it is a "plugin" based application, where the real-time instantiation of the particular plugin causes the instantiation of the ISession. The main program does not nor should not have the access to it.

4. Enabling the library log is not an option: I cannot enable such an extended logging on the production site which thousands of securities being requested. It would degrade the performance and fill the rotating logs with such a speed that nobody would be able to collect them before the previous info is overridden.

5. Since the usual callback does not seem to work, what is the strategy the you propose to handle this event?
For me it is obvious, that server application should never just cut the connection.

6. How should I proceed with this issue? Should I report it through the LSEG Support? This is an important issue that should be handled at the library side.

Thanks

Patrick Z

Jirapongse

@PatrickZ

We don't have permission to access to server to verify the connection. You need to contact the product support team directly via LSEG support to verify this. Please include the URL of this discussion in your raised question to prevent it from being redirected back to this Q&A forum. Moreover, if you have firewall or proxy servers, you may need to contact your IT support team to verify if the disconnection is from the firewall or proxy servers
Under the hood, the library communicates via REST APIs using HTTP requests and responses, making it inherently stateless. A session within the library is represented by a session token. Upon startup, the library requests a token from the Data Platform's authentication service. As long as the token remains valid, it can be used to initiate new connections and retrieve data—effectively indicating that the session is still active.

I tested this behavior by disabling the network after the session was opened. As a result, the library was unable to refresh the token once it expired. In this scenario, the session state transitioned to Pending because the session token was no longer valid.

3. I checked and found that the application can use the try/catch block to catch this disconnection exception. You need to use the try/catch block when using the EndpointRequest. For example:

            using ISession session = Configuration.Sessions.GetSession(Configuration.Sessions.SessionTypeEnum.RDPv1);


            // Open the session

            session.Open();


            try

            {


                var datagrid_endpoint = EndpointRequest.Definition( "/data/datagrid/beta1/").Method(EndpointRequest.Method.POST);



                var request1 = new JObject()

                {

                  …


                };


                var response = await datagrid_endpoint.BodyParameters(request1).GetDataAsync();

                Console.WriteLine(response.Data.Raw.ToString());



            }

            catch (Exception e)

            {

                Console.WriteLine($"\n#### Exception **************\nFailed to execute.");

                Console.WriteLine($"Exception: {e.GetType().Name} {e.Message}");

                if (e.InnerException is not null) Console.WriteLine(e.InnerException);

                Console.WriteLine("***************");

            }

PatrickZ

https://community.developers.refinitiv.com/discussion/comment/127731#Comment_127731

I read your comment a little perplexed.

1. If I understand well, after the socket connection is reset ("existing connection was forcibly closed by the remote host") by the server, the client application, as long as the token is valid, so up to 600 seconds (!), can still request and receive the data!

This seems to (at least partially) confirmed by the logs I received, because after the connection was reset, I still see plenty of request/response activity. The reset was at ~2025-08-25 13:14:19 local time, and I see the activity until ~2025-08-25 13:18:21. Unfortunately, the log I received ends at this moment, because the person that extracted it did not wait any longer…

So, am I correct assuming that for about 6 more minutes everything would go smoothly and then the library would issue another token refresh request, but NOT because the connection was broken, but because the ...token has expired?

If so, is it necessary to do anything in this case about the connection reset? At the next round (our application is a scheduler based) of requests, the application would request the new token anyways and the things would continue as usual. Please confirm!

2. If the catching would be required (I already have a try/catch at the higher level (but obviously below the Main program level), well, I wonder if it would be even a good idea, since there is a problem with identifying the kind of exception. There is no specific exception type, nor a particular error code and we cannot arbitrarily decide that it is the connection reset.

3. I still think that the Session class should own the socket and catching any socket exception in the Session class would enable it the change of the session status and therefore use the callbacks to communicate "normally" with the client application

4. What are the potential reasons for the server to reset the connection? Possibly a slow consumer? Is there anything recommended to do at the client level to avoid this kind of problems?

Thanks

P. Zalewski

Jirapongse

According to my test, as long as the session is still open, the application can use it to retrieve data
The exception that I got when I cut the connection is HttpRequestException
You need to contact the server team to verify the server log or contact your IT support to verify the network settings

PatrickZ

https://community.developers.refinitiv.com/discussion/comment/127759#Comment_127759

Thanks for your answer.

regarding the session state. You confirm that that while the session is still Opened, the application can request the data. The problem is that the transition of the session state is unclear and there seem not to be any documentation regarding it.
The situation that we face is, I repeat, "existing connection was forcibly closed by the remote host", This is particularly with the subscription (by subscription I mean using the PricingStream and adding the RICs to the stream to receive the updates). The only thing to simulate the situation is to cut the network. After I do this, I observed, that the session state remains Opened for the time remaining form the cut off time up to the 600 seconds period, i.e. until I receive TokenRefreshFailed event. Then the session state becomes Pending.
Reconnecting the network after a certain time, generally brings a pretty strange cascade of events:
-StreamConnected
-StreamAuthenticationFailed
-StreamDisconnected
-StreamConnected
-StreamAuthenticationSuccess
followed by the session state becoming Opened

Re-establishing the network, even after a longer time period, like 15 minutes always makes the session pass from Pending to Opened.
In other words, on the client side I never been able to provoke the situation when the session state would become Closed.

Now, from the server side, I wonder whether:
1. if the server side cuts/resets the connection (at the socket level), what will be the state of the session? Pending or Closed?
2. Can the session become Closed because of the events on the server side?
3. if the server side cuts resets the connection, is the instance of my ISession still "good" in the sense that I do not need to call again IPlatformSessionDefinition.GetSession()?
4. Once I have the instance of ISession, can I indefinitely change the state from Close to Open and then again close it and reopen as many times that I want without calling GetSession() for the same credentials)?
In other words, in normal circumstances, an application should call GetSession() only once and, depending on the needs just Open/Close it indefinitely?
5. Can you provide any document that describes the Session's state transitions?

Thanks

Jirapongse

Under the hood, the library communicates with the Data Platform via REST APIs using HTTP requests and responses, making it inherently stateless.

A session within the library is represented by a session token, which is requested from the platform’s authentication service during startup. As long as the token remains valid, it can be used to initiate new connections and retrieve data—indicating that the session is active. Importantly, the session token is not directly tied to connection resets.

Session tokens expire after 10 minutes, so the library must refresh them periodically. If the token refresh process fails, the session transitions to a Pending state and continues retrying. Once a new token is successfully obtained, the session returns to the Opened state.

The session is explicitly closed when the application calls the session.close() method.

PatrickZ

https://community.developers.refinitiv.com/discussion/comment/128101#Comment_128101

Thank you for your answer and a high level description of how the session behaves.
I need the answer to some more detailed questions:
1. Can ever the session become Closed because of the events/actions on the server side?

2. Once the session instance is retrieved using IPlatformSessionDefinition.GetSession() (for example at the application startup), are there any circumstances to call the GetSession() again (assuming the user credentials did not change)?

3. Once ISession is closed explicitly, can it be opened again or the proper way of action is to dispose of the instance and call GetSession() and open the new instance?

4. Also, regarding my original question about the server side socket reset and your advice to

"You need to use the try/catch block when using the EndpointRequest"

When this happens, (besides catching the exception so it does not propagate) is there any specific action to be done in the catch to handle this? Is it guaranteed that on the client side the session will become first Pending and then, after the socket is reestablished, it will be Opened again?

4. Is there any documentation available regarding the session?

Thank you

PatrickZ

https://community.developers.refinitiv.com/discussion/comment/128106#Comment_128106

Hello again!
As explained I try simulating the web socket failure by cutting the network access. When done, the session stat would be Pending trying then to reestablish the connection every 15 seconds. After restoring the network access, ISession would recover by first passing the status from Pending to Open and then (if the token expired) by sending Password Grant Refresh request. Until today, it always worked, but today I found another condition: the RDP access token refresh failed with the Status:
Status response: {
"ID": 1,
"Type": "Status",
"Domain": "Login",
"Key": {
"NameType": 5,
"Elements": {
"AuthenticationErrorCode": 1026,
"AuthenticationErrorText": "Request for token validation failed:Authentication server did not contain "active" in response"
}
},
"State": {
"Stream": "Closed",
"Data": "Suspect",
"Code": "UserAccessToAppDenied",
"Text": "Authentication failed (1026, Request for token validation failed:Authentication server did not contain "active" in response)."
}
}
It looks like that server got rid of my session info. Following this, my application had to wait for another 10 minutes (600s) to issue another Password Grant Refresh, which was, this time successful.

QUESTION: what is the recommended course of action in this case? My application cannot wait 10 minutes to have another token refresh. Should I (after intercepting UserAccessToAppDenied status), close the existing session, dispose of it and call again?Please look into this case, since it is important.

I have the impression that you respond only with the optimistic scenarios, however the reality is that things can go other way. Also, there are the previous questions that I reposted earlier today.
Please, see the attached log file for the details. The is at time stamp of reception of "UserAccessToAppDenied" status 2025-09-26 16:00:14,034 (line 92)

Thank you

UserAccessToAppDenied_followingReconenction_20250926.txt

Jirapongse

@PatrickZ
These questions require in-depth knowledge of the library. I will reach out to the product team to verify them.

nick.zincone

Hi @PatrickZ

I went through the details of this conversation and want to make a few observations/comments.

Are you setting the TakeExclusiveSignonControl to false to protect the situation if another application is already running with the same credentials?
Can you elaborate this point "Why the session event handlers do not work on "forcibly closed"?"
The session is a stateless connection and only communicates to the server at .Open() and when it needs to refresh a token. The .OnState/.OnEvent are mostly designed around session establishment, not capturing network communication issues for sending HTTP GET/POST data requests. If you send a request for data and you receive an exception, this isn't an issue with the logical, stateless session, but rather what appears to be a network issue on the specific HTTP request.
The session is really designed to maintain an access token in order to get data. Upon .Open(), it will go through a login phase to retrieve an access token - no connection is established - it is stateless. The login response will determine when to refresh the access token - set to 600 seconds.
The session state does not change, i.e. move to a Closed state, if there are network (or other) issues trying to get data. This is because the session is still holding on to a valid access token and can still be used.
Trying to force a session close/open will do nothing other than get a new access token. The errors you are receiving is independent of the session. If the session state does change to close, because it fails to retrieve an access token due to issues, then a .Open() can be used to try to get a new token.
If you choose to stream, i.e. when you are using the 'Pricing' interface, the underlying websocket connection will be managed by the session but the session is still considered "Open", even if you receive a disconnect on the stream. The library will attempt to reconnect every 15 seconds as you noted. The reason the session is still considered open is because an Open session is basically a session where the access token is valid. If you have an application that is retrieving Historical Pricing data and also streaming prices, you can still continue to get historical data even if the stream disconnects - they are independent access points.

The above was just to address some of the questions around behavior. That being said, there could be an argument to utilize the .OnEvent/.OnState within a session to capture certain data error events. Because we are utilizing the sessions token, we could report events with that session. But we still need to figure what is going on. Now, normally I would suggest to try to replicate with an existing application we have available within the GitHub Example package. However, I don't know if you can on this particular machine.

When did you start to notice network/communication issues? More specifically, has this been running okay in production for some time? Do you have the same application successfully running within a dev environment?

amihaita

https://community.developers.refinitiv.com/discussion/comment/128108#Comment_128108

Hello @PatrickZ ,

Thank you for reaching out to us. I've reviewed the log file you posted, and it helped uncover a rare timing issue where two of our internal timers overlap:

Line 25 – The stream is reconnecting due to the network reconnection (the 15-second re-establishing delay you mentioned).
Line 36 – A new token is being requested while the initial stream connection is still in progress. → token expiry time

Because these two actions interfere with each other, we end up sending a login message with the old access token instead of using the newly acquired one (see line 66).

Thanks to your test, we've identified this as a bug, and we'll solve it accordingly.

Answer to the question:
In case you encounter this specific timing issue, the best approach—just as you suggested—is to close the session and open a new one based on the StreamDisconnected callback event. This way, you can avoid relying on the 600-second (10-minute) token expiry, which would otherwise trigger a new socket connection.

Regarding some documentation, you can consult the following link, where our sessions are described:

Definition and Use Cases

PatrickZ

https://community.developers.refinitiv.com/discussion/comment/128132#Comment_128132

Hello Nick

Maybe I will put some context into my questions, so we can better understand the situation.

1. We got some server-side disconnects which prompted us to look deeper into logs. The “ConnectionResets” (with the message “Message: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..” ) were found primarily while requesting the data on some Fundamentals endpoints and they were not that important since they were caught. However, we noticed some issues with the subscription, when the requests were not done because of the Pending session status.

2. As it is impossible to repeat exactly what was happening, we tried to simulate the situation by cutting the network to the dev machine to see how the ISession behaves. Then we have seen how the session transitions state when the network connection is cut and then re-established. USUALLY when the stream gets Disconncted, it retries to reconnect every 15 seconds but the session stays Opened until the current token expires. Then the session becomes Pending.When the reconnection is made (StreamConnected), first it fails authentication (StreamAuthenticationFailed) and disconnects again (StreamDisconnected), then it connects again (StreamConnected) and gets authenticated (StreamAuthenticationSuccess) to finally allow the return to the sessions Opened state.UNFORTUNATELY, sometimes this is NOT what always happens. A couple of days ago, after the connection was restored, the session status passed first from Pending to Open, then the Authentication failed, and the application stayed “dead” for 600 second when another “Password Grant Refresh request” was sent.This is what is contained in the attached file “UserAccessToAppDenied_followingReconnection_20250926.txt”. It looks like the sequence of events was completely wrong.

3. As our client cannot tolerate a 600s break in service, we are looking to find the way to restart the session automatically, upon detection of certain conditions.This is why I asked all the questions regarding closing the session and calling again the GetSession().From your answer it looks like we do not need to dispose of the ISession, so we never need to call GetSession() except one time at the beginning of the application run.If it is possible to close the session and “restart it”, what are exactly the conditions at which we should do it? Is the condition from 20250926 (SessionOpened with StreamAuthenticationFailed) even possible? Also, the “usual” sequence (StreamConnected – > StreamAuthenticationFailed -> StreamDisconnected -> StreamConnected -> StreamAuthenticationSuccess) at the reconnection is somehow difficult to catch…Essentially, I am looking for the strategy to implement the session restart upon detection of certain conditions. So, first, what are the conditions (session state, stream state) that would prompt us to try to restart the session? Secondly, what is the recommended sequence of calls?

What I explained above, I found when using the Pricing interface, but only a part of our application uses the Pricing. We still have the Historicals and Fundamentals. The application is configurable and can be used to acquire only pricing items (subscription) or only Fundamentals (from endpoints) or only Historicals (Summaries) or any combination of them. Obviously with Fundamentals request we are not adding anything to stream, however the session used there has the same “session manager” as the subscription part. I assume that the session state transitions are still the same, when the endpoints or summaries are being used.

4. Regarding the TakeExclusiveSignonControl, I am surprised by this question. This is set to True in our application, so I am not sure what prompts you to state so. Our application has an exposed rout that allows us to make the GET requests during the application run-time and I can clearly see that the value taken from the ISession property is True

Thanks
Patrick Z. Zalewski

EXPLORE OUR SITES