Isn't if the server did not receive any messages from the client within the (1.5) * KeepAlivetime and the client did not send any PINGREQ within the aforementioned period, the server should DISCONNECT?
If yes, why I am receiving LWT message which is should not be received as DISCONNECT occures?
Last will and Testement will be sent if the client does not explicitly disconnect it's self.
If the broker disconnects the client due to a ping time out then the LWT will be sent, this is the specific reason why the LWT feature exists.
Or do you mean your now disconnected client is receiving it's own LWT?
Related
I have a server written in C that closes the connection if the connection is sitting idle for a specific time. I have an issue (that rarely happens). Read is failing on the client side and it says Connection broken. I suspect the server is closing the connection and the client is sending some data at the same time.
Consider the following scenario (A is server, B is the client)
B initiates the connection and the connection between A and B is established.
B is sitting idle and the idle timeout is reached.
A initiates the close
Before B receives the FIN from A, it starts sending request to A
After B sends the request, it will read the response
Since A has already closed the connection, B is not able to read.
My questions are
Is this a possible situation ?
How to handle idle timeout for clients?
How to close the connection between A and B properly (avoid B sending request during the process). In short, how to close the connection atomically?
By my only little more than rudimentary network experience... and assuming that you are talking about a connection-oriented connection like TCP/IP in contrary to UDP/IP that is connection-less.
Yes, of course. You cannot avoid it.
There are multiple ways to do it, but all of them include: Send something from the client before the server's timeout elapses. If the client has no data to send, let it send something like a "life sign". This could be an empty data message, it all depends on your application protocol. Or make the timeout as long as necessary, including some margin. Some protocol timeout only after 3 times of allowed idle time.
You cannot close the connection atomically, because client and server are separated. Each packet on the network needs some time to be transmitted, and both can start sending at the very same moment, the server its closing message, and the client a new data message. There is nothing that you can do about this.
You need to make the client handle this situation properly. For example, it can accept such a broken connection and interpret it as closed. You should have already some reaction, if the server closes the connection while the client is idle.
How to close the connection between A and B properly (avoid B sending request during the process).
Server detects timeout
Server sends timeout detection message to the Client
Server waits for a reply (if timeout, assume Client dead)
if Client receives a timeout detection from the Server, it replies with ACK (or something like that)
if Server receives an ACK from the Client, then 'gracefully' closes the connection
from now on, neither the Server nor the Client should send/receive any messages (after sending the ACK, do not immediately close the connection from the client side, do linger for the agreed timeout - see setsockopt: SO_LINGER)
On top of that, like the other answers suggested, the Client should send a heartbeat if idle (to avoid timeout detections).
My server main thread run infinite while loop to accept connection from clients. After a server get connected with one client, it allocate a thread to handle client task, then close connection. After the task finish, I want my a allocated thread to send data back to the client. How can I achieve this? THank you so much.
client1 --connect--> server --ask--> thread A to do a task that client1 ask to do
close connection
Thread A finished the task, wanna send back result >>>> How?
Don't close the connection before sending the response back.
When a client opens a connection there are really two communication channels involved. One is made by the client to the server, the second is made by the server to the client. When you "accept" a connection on the server side, the remainder the client communication channel is also fully established.
By closing the connection, you destroy both channels. If your server attempted to respond, the client has already received the close indicators, and has destroyed its ability to receive your data.
I have been facing this issue for my Solr instance which is managed by Zookeeper.
It appears that Zookeeper is able to send requests to Zookeeper which momentarily accepts the request and then refuses it.
In Zookeeper logs, I have been seeing this error:
INFO org.apache.zookeeper.ZooKeeper.Client.environment:user.dir=/ [1635628661#qtp-2049348234-50]
INFO org.apache.zookeeper.ZooKeeper Initiating client connection, connectString=localhost:2181 sessionTimeout=150000 watcher=org.apache.curator.ConnectionState#c4f2fbd [1635628661#qtp-2049348234-50]
INFO org.apache.zookeeper.ClientCnxn Opening socket connection to server localhost/127.0.0.1:2181. Will not attempt to authenticate using SASL (unknown error) [1635628661#qtp-2049348234-50-SendThread(localhost:2181)]
INFO org.apache.zookeeper.ClientCnxn Socket connection established to localhost/127.0.0.1:2181, initiating session [1635628661#qtp-2049348234-50 SendThread(localhost:2181)]
ERROR org.apache.curator.ConnectionState Connection timed out for connection string (localhost:2181) and timeout (15000) / elapsed (15290) [1635628661#qtp-204934823450]
org.apache.curator.CuratorConnectionLossException: KeeperErrorCode = ConnectionLoss
at org.apache.curator.ConnectionState.checkTimeouts(ConnectionState.java:191)
at org.apache.curator.ConnectionState.getZooKeeper(ConnectionState.java:86)
at org.apache.curator.CuratorZookeeperClient.getZooKeeper(CuratorZookeeperClient.java:113)
at org.apache.curator.framework.imps.CuratorFrameworkImpl getZooKeeper(CuratorF
Any help is appreciated here.
According to log you have opened socket on localhost:2181, so line:
INFO org.apache.zookeeper.ClientCnxn Socket connection established to localhost/127.0.0.1:2181, initiating session [1635628661#qtp-2049348234-50 SendThread(localhost:2181)]
Is states like, ok, we found an opened socket, now we attempt to write some data. And it sends connection request sending sessionId and password. If session is not already established - it is sends 0 as session id, but sends password.
If you will enable debug output you would see in log then something like
Session establishment request sent on <remote address>
Log record you asking about -
ERROR org.apache.curator.ConnectionState Connection timed out for connection string (localhost:2181) and timeout (15000) / elapsed (15290) [1635628661#qtp-204934823450]
related to curator itself. If client not connected - it call checkTimeout() and if check timeout result is 'CONNECTION_TIMEOUT' generates record like above.
Not so much information but I try to guess there is zookeper on your localhost but connection rejected, may be password required or something else.
Hope it will help.
(my answer is based on curator code from master here -> https://github.com/apache/curator)
i've got this problem, in a test program, where i'm developing a client for MQTT, i'm subscribed on a topic, after that, i wait for "publish" message from the server to my client.
After a good recv (of a publish message) or after a recv timeout i send a mqtt PINGREQ to the server.
After a A PINGREQ i'm going to wait a PINGRESP, then i call a recv as in the case I were waiting for a PUBLISH message.
If the flow is this:
Client -> PINGREQ
Server -> PUBLISH
Server -> PINGRESP
Than the server publish message were lost. How to solve this? I'm using MQTT at QOS 0, it make sense solve this problem on this level of QOS or instead is smart to check this case at QOS1?
I think you've got things a bit confused. PINGREQ/PINGRESP are used when there isn't any other network traffic passing between the client and server, in order to let both the client and server know if the connection drops.
Your client should keep track of the when the last outgoing or incoming communication with the server was, and send a PINGREQ if it is going to exceed the keepalive timer it set with its CONNECT command. The server will disconnect the client at 1.5*keepalive if no communication is received. The client should assume the server has been disconnected if it does not receive a PINGRESP in response to its PINGREQ within keepalive of sending the PINGREQ.
The QoS level isn't that important, you have to ensure the keepalive timeout is maintained regardless.
It also occurs to me that it sounds like you're using blocking network calls - it might be best to move to non-blocking if you can to get more flexibility.
I have configured Service Broker communication between two SQL Server 2008 instances using Windows authentication. I am sending a message from Initiator Service to Target Service and then ending the conversation in the target. Since target is not sending a reply message back to initiator, does the Target Instance need to have any Route configured for sending system generated acknowledgement messages to Initiator? Can I only rely on conversation handle in Target instance to communicate back to Initiator?
Thanks in advance.
A route is always needed in both directions. Even if you never send messages explicitly from the target, the target still needs to send implicit acknowledgements for each message received.
But in your case you are sending an explicit message: END CONVERSATION sends an http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog message.