I am using Openfire 3.9.3 and had created web chat application with strope.js. When the less number of user on openfire were there the connection was stable. but there are lots of users registered on that app.
Users are not online still my connection disconnected repeatedly I again connect on_disconnected(). The connection is made but again it get disconnected with
NetworkError: 404 Invalid SID. - http://127.0.0.1:7070/http-bind/
is it client side defect or server side defect?
How to solve this?
Openfire generally pings the client on a regular interval to check if the client is alive. When the client fails to respond within the specified timeout, the server infers the client has disconnected.
The error you are getting is page not found error which basically means that either there is some problem with your listening port or network.
However since you are using loopback address, the network possibility is ruled out. Check your server port as I (even though the code is not given for reference) feel that your client may not have any problems. Just make sure the binding address is up and right.
I had the same problem in my code (I'm using my version of Candy Chat), and the problem was I wasn't calling the BOSH _proto version of _doDisconnect in time.
_doDisconnect: function ()
{
this.sid = null;
this.rid = Math.floor(Math.random() * 4294967295);
window.sessionStorage.removeItem('strophe-bosh-session');
},
You must make sure this is called before your code calls the Strophe _changeConnectStatus function for a disconnect. Or at least set the current connection this.sid = null.
In other words, you have to make sure Strophe nulls the current "sid" value so the next ping sends no "sid" or a new one (I think none, but might be a new one). If not, your client side next "send" ping has the old value in it even though the server now disconnecting. Then the server gives the not very informative 404 error, which is actually letting you know that that connection is no longer valid (which of course is what I wanted in the first place). Sort of a which came first, the chicken or the egg problem.
Hope that helps a little with one version of why that error comes up. The standard version of Candy Chat resets everything before every connection attempt, so it doesn't have this problem.
update keepalive value at client side. default is 120 seconds.
Related
When establishing a web socket connection between client to server the connection can close unexpectedly for several reasons:
Inactivity on the TCP channel.
server issue which makes the connection to close.
Client crash or reload/ refresh.
I am looking for the way of dealing with such situations or, at least, know they occurred.
When reading about WebSocket close, I understood the WebSocket protocol support server initiated pings pongs which can be used for the server to know if a client has crashed. (client initiated ping pong are not supported). - is it the best way to deal with client crash?
Also, I see in spec that on the client side we can listen to the onClose event and that there are several codes to understand why connection has been closed -
When the server crashed is that onClose event is always called?
Both server and clients can send pings, however there is no method in the Javascript API to send such control frames.
A common approach is to send protocol level pings from the server to client regularly. If the server does not get a pong frame in a given time, the server disconnects the client.
However, clients should also know if the server is unreachable or the connection is half open, so having an application level ping/pong (i.e.: some user data representing a ping or pong) would allow both server and client figure out if the other end is not reachable anymore. As before, the server can send pings and expect pongs in a given time, but also the client can expect to have pings in a given time or consider itself disconnected, and then try to reconnect again.
About closing reasons, worth to check : getting the reason why websockets closed
If the server crashes and the connection remains half open, you will have to detect this situation yourself and call .close() on the WebSocket object, and then the onclose event will be called.
A customer of mine has a Windows application where there is a network connection between two machines. The system is supposed to cope with the connection being lost. It does this by keeping a counter on the client position which is reset every time data is received from the server. If the counter reaches 60 seconds (i.e. we haven't heard from the server for 60 seconds) it performs some expected action to cope with the connection being lost.
The customer has a problem, however, where sometimes the connection will be lost but the client doesn't perform the expected action. Upon investigation, it appears that this is an intermittent problem caused by the client's socket to the server sometimes raising error 10057 (WSAENOTCONN / "Socket is not connected") when the connection is lost. Because the client behaves differently when it gets a socket error the customer doesn't get the desired behaviour when they get this socket error. This is not difficult for me to fix, but I am a bit puzzled by the different behaviour.
To reproduce the problem I'm physically pulling the network cable out of the back of my server machine. The majority of the time, the effect on the client side is that we just don't get any data over the socket, and we don't get an error. Some fraction of the time however error 10057 is raised. Can anyone shed any light on why there is this inconsistency? The client socket is a nonblocking STREAM socket.
I would expect you would get an error only if you try to send something. That is when the TCP connection would discover it can't reach the other end point. This will take a variable amount of time to discover the failure, depending on the network round trip time. There might be a "keep alive" option, that forces the socket to periodically send something to detect failure even when app is idle.
WSAENOTCONN is a bug in your application. It isn't a result of a lost connection. The result of a lost connection is WSAECONNRESET. Your code must have got WSAECONNRESET, and then proceed to use the connection as though it was still valid. Then you get WSAENOTCONN.
The XMPP spec states that the client should broadcast presence upon connecting to an XMPP server. Strophe has two methods to "connect" to an XMPP server: connect and attach. Connect does a full authorization and attach is for reconnecting to a pre-existing connection. When using attach, should the client broadcast presence to the server?
In my testing, it appears that if I do not broadcast presence on attach, the client does not receive messages (presence, message, or otherwise) from other users, and if the client attempts to send any stanzas, he is immediately disconnected by the server. It's as if the server has no idea the user is connected without the presence broadcast.
This seems as if I answered my own question, however, I'm wondering if there is perhaps a bug in the server or if I'm doing something wrong or is this expected behavior?
There is a bug somewhere - attaching is literally attaching - you are continuing the original session. The server doesn't even know it happened!
Something to watch out for - if you have the old code still open, and you have multiple things using the same session, you could easily end up with something like you describe.
If you're still stuck, it might be useful to see some code, or at least a log of the attached session (e.g. the disconnection from the server - what error does it give, etc.?).
We're attempting to network between an iphone and a computer (windows 7) using TCP/IP over Wifi. We are having a lot of difficulty setting up this basic network and we were hoping to get some guidance.
Server side:
Currently, we are trying to use MATLAB's tcpip protocol to set up the connection on the computer. We have determined the IP addresses of the phone and the computer and we picked a port number (501), that we are trying to read and write from. We allowed that port number in windows firewall.
In simulink we set up a TCP/IP send block to send out a constant, by double-clicking on that block and selecting the "verify address and port connectivity" button we get the error message:
"The remote address '140.180.....' has been found. However, we are unable to connect to the server at the specified port.
Specify a different port or wait for the current port to become available"
We have tried other port numbers, but gotten the same message.
We have tried using an ad hoc connection between the computer and the iphone to the same effect.
We have also tried other MATLAB scripts to set up the connection (e.g. http://www.mathworks.com/matlabcentral/fileexchange/24524) but we always get and error in the connection
Finally, we tried sending and receiving info over TCP/IP with the same computer using two MATLAB instances running in parallel, but we generally get the same error message.
We even tried UDP...no dice.
Client side (iphone)
We're using NSStream exactly as per this tutorial: http://www.devx.com/wireless/Article/43551/1954
The stream is opened upon a toggle action, and we immediately send a string to the server. We also tried sending a continuous sequence of data with the run loop. One strange bit of behavior is that, after the stream is open for a little while (~1 min), the handleEvent method does seem to get triggered (implying something is received from the server??) because we get a log message corresponding to case NSStreamEventErrorOccurred.
We think the issue lies on the server side, but really don't know enough to be sure or to debug properly. Any help would be very much appreciated.
A long overdue answer to this one: don't network with Windows. We eventually thought to switch over to a mac and lo and behold everything worked properly.
i need some help with socket.listen.
my max_connections is set to 1. but even after a client is connected if another client tries to connect, on the client side it says it has connected although the server does not report anything new.
my app is between one server and one client. and if any other client tries to connect while there is already a connection i want that connect to be refused.
please help with some ideas.
thank you very much.
You didn't supply any code, but the title of your post references Socket.Listen. The parameter given to Socket.Listen is not the maximum number of connections, rather it is the size of the "backlog" of incoming connections.
What that means is that when someone tries to connect, but your server hasn't Accept()ed the connection yet, those clients are in the "backlog" queue. You've set the size to 1, so only 1 client can be waiting to connect at a time.
This parameter does not have an effect on the total number of connections allowed to your application.
You can use the IsConnected property on your TCPClient to check if a connection already exists and decide upon that.
I propose you to accept new client connection but acquire the semaphor immediately before access to wrapped server and release it immediately after access. This approach allows you to control how many clients are using wrapped server concurrently.