I have a WCF Websocket client server communication. What I want to do on client side, is to keep trying to reconnect to the server, if server was shut down or something. From what I know, once a server is shut down, channel is in faulted state so I cannot use it again. I need to create a new one, but I am afraid, that there is memory leak in my solution:
creating the websocket service:
InstanceContext context = new InstanceContext(this);
ServiceReference.SomeServiceClient client = new ServiceReference.MLogDbServiceClient(context);
reconnecting:
client.Abort();
client = new ServiceReference.MLogDbServiceClient(context);
In Windows Task Manager I saw that in two minutes my app grew from 29mb to 48mb while I was keeping to create new channel every 20ms ( it was just for memory leak test purposes ). Anyone has a leak-free solution for me?
My client application NEEDS to keep reconnecting to the server (not so frequently but still). Greetings
Related
I am trying to set Disconnect Timeout to higher value from the default 30s.
All examples on web are more JS oriented.
var hubConnection = new HubConnection("http://localhost:8087");
var testHubProxy = hubConnection.CreateHubProxy("TestHub");
Error: System.TimeoutException: Couldn't reconnect within the configured timeout of 00:00:30, disconnecting.
This did not work:
GlobalHost.Configuration.DisconnectTimeout = TimeSpan.FromSeconds(35);
Update:
It looks like DisconnectTimeout needs to be set on the server side!?
What is the reason for disallowing different clients to have different Disconnect Timeout?
Disconnect Timeout is configured on server-side. The main reasons could be as follows:
We know the server may take some N-time units to respond so that the all clients may be well aware.
The server should be pinging the clients for connection at regular times. So the server is aware of clients connection and can manage other hubs and eradicate the expired connections from its connection pool.
The client is not supposed to set disconnect timeout because it does not know when could it shutdown e.g. the internet switched off accidentally on client side than the client is not able to tell server that I am not going to connect to you again. Yes but we have some events at client-side which tells it that it is not connected to the signalr hub anymore. Please see the reconnecting and disconnected events.
Summary:
Disconnect timeout is to inform the server that its client is not connected anymore even if it disconnects disgracefully .
I need to make persistance connection to Aerospike noSQL DB in a Web service.
In a not-Web application, connection is straightfoward as
using (AerospikeClient client = new AerospikeClient("127.0.0.1", 3000))
{
...
}
But in a Web service application, creating new client for each request is expensive. The Best Practices say this too: "use only one client instance per cluster in a program and share that instance among multiple threads. AerospikeClient and AsyncClient are thread-safe."
I can make a static object, but what if the client disconnects, either by error or timeout (24 hours max connection living time)? Can anyone provide any fault-tolerant code spippet? (Maybe similar to redis pattern How does ConnectionMultiplexer deal with disconnects?)
The client manages a socket pool. If a socket error or timeout occurs, the socket is disposed of.
I'm using NetworkComms.Net and I'm currently trying to create a sort of forwarder which listens on a port (calling it GATEWAY), which receive a certain packet (from CLIENT) which will tell him where to redirect next pacekts coming from the same client.
Example:
CLIENT tell GATEWAY that he needs to get to SERVER:serverport
GATEWAY creates a connection to SERVER:serverport
CLIENT sends packets to GATEWAY which sends them to SERVER
SERVER sends back a response, which goes through the GATEWAY to the CLIENT.
I had it working with Net.Sockets and I’m now changing to NetworkComms.
The problem I’m facing is that when a connection from Gateway (client) to Server (listening server) is closed, the Gateway trigger the global callbacks for connection/disconnection:
NetworkComms.AppendGlobalConnectionCloseHandler(ClientDisconnected);
NetworkComms.AppendGlobalConnectionEstablishHandler(ClientConnected);
Those callbacks are supposed to be only called when a client connect or disconnect on the Gateway
This is the code i’m currently using to start the listener.
NetworkComms.DefaultSendReceiveOptions = new SendReceiveOptions<ProtobufSerializer, , LZMACompressor>();
NetworkComms.DefaultSendReceiveOptions.IncludePacketConstructionTime = NetworkComms.DefaultSendReceiveOptions.ReceiveHandlePriority = QueueItemPriority.AboveNormal;
NetworkComms.AppendGlobalConnectionCloseHandler(SessionClosed);
NetworkComms.AppendGlobalConnectionEstablishHandler(NewSessionConnected);
NetworkComms.AppendGlobalIncomingPacketHandler<string>("ECHO", SocketCommands.HandleIncomingECHOPacket);
Connection.StartListening(ConnectionType.TCP, new IPEndPoint(IPAddress.Any, 10000));
I suppose this is like a “global” way of starting It?
How do I start one then add those Connected/Disconnected handlers to just the listener?
Thanks
hopefully a simple WCF beginners question..
I have a WCF channel factory, returning a service proxy TChannel:
// setup connection to server
var endpointAddress = new EndpointAddress(GetAppSetting("Endpoint"));
var tcpBinding = new NetTcpBinding();
channelFactory = new DuplexChannelFactory<IExcelServer>(this, tcpBinding, endpointAddress);
server = channelFactory.CreateChannel();
I would like to know when this service proxy changes state (Faulted, Closed etc). I can see events on the ChannelFactory itself, however I'm not sure this is the same as the channel itself, and even here stopping the server process doesn't cause a state transition.
This is a CallbackContract service, and in almost all interactions the server is sending data to the client. Therefore I can't simply rely on catching the failure when I make a server call from the client.
Should I send a heartbeat from client to server to trigger the state change?
The instance you get back from CreateChannel implements TChannel but also IClientChannel which has state changed events like Closed, Closing, Opened, etc.:
server = channelFactory.CreateChannel();
((IClientChannel)server).Faulted += FaultedHandler;
P.S: As you pointed out, the states of the channel and channel factory are related but not the same. If a Channel is faulted it doesn't necessarily mean that the ChannelFactory is.
Error:
Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall
Situation
There is a TCP Server
My web application connects to this TCP Server
Using the below code:
TcpClientInfo = new TcpClient();
_result = TcpClientInfo.BeginConnect(<serverAddress>,<portNumber>, null, null);
bool success = _result.AsyncWaitHandle.WaitOne(20000, true);
if (!success)
{
TcpClientInfo.Close();
throw new Exception("Connection Timeout: Failed to establish connection.");
}
NetworkStreamInfo = TcpClientInfo.GetStream();
NetworkStreamInfo.ReadTimeout = 20000;
2 Users use the same application from two different location to access information from this server at the SAME TIME
Server takes around 2sec to reply
Both Connect
But One of the user gets above error
"Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall"
when trying to read data from stream
How can I resolve this issue?
Use a better way of connecting to the server
Can't because it's a server issue
if a server issue, how should the server handle request to avoid this problem
This looks Windows-specific to me, which isn't my strong point, but...
You don't show us the server code, only the client code. I can only assume, then, that your server code accepts a socket connection, does its magic, sends something back, and closes the client connection. If this is your case, then that's the problem.
The accept() call is a blocking one that waits for the next client connection attempt and binds to it. There may be a queue of connection attempts created and administered by the OS, but it can still only accept one connection at a time.
If you want to be able to handle multiple simultaneous requests, you have to change your server to call accept(), and when a new connection comes in, launch a worker thread/process to handle the request and go back to the top of the loop where the accept() is. So the main loop hands off the actual work to another thread/process so it can get back to the business of waiting for the next connection attempt.
Real server applications are more complex than this. They launch a bunch of "worker bee" threads/processes in a pool and reuse them for future requests. Web servers do this, for instance.
If my assumptions about your server code are wrong, please enlighten us as to what it looks like.
Just a thought.
If your server takes 2seconds to response, shouldn't the Timeout values be 2000, instead of 20000 (which is 20 seconds)? First argument for AsyncWaitHandle.WaitOne() is in milliseconds.
If you are waiting 20 seconds, may be your server is disconnecting you for being idle?