powered by Jive Software

Can openfire detect broken connection?

Hello there,

How openfire detect broken connection(e.g network error,client cable accidentally pull off,etc.). ive read same problem here in this forum but i havent seen clear solution to my problem…im using openfire 3.6.3. what i want to happen is openfire detect client broken connection and drop his session ryt away…in order for other clients receive unavailable presence to that disconnected client due to network error or something…by the way,im using agsxmpp library…can u help me what i need to be set in openfire to resolve this problem?

i really want a result that if the client disconnected due to network error or something…i want openfire detect in right away and drop his session.for the sake of other client to receive unavailable presence to that disconnected client…

thanks in adcance for all the reply.

glen

Hello, i really need opinion about this problem i am dependent on your answer guys…pls…

my problem remain unsolve.pls share your idea on how to handle this problem…

many thanks…

glen

Probably this depends on every network setup. I can only setup such testing environment: PC with internet connected to one lan card and shared with ICS to second lan card. Notebook connected to second PC’s card. Openfire 3.6.4 running on that PC. Spark client connected on a notebook. Then i disable shared internet connection on a PC. And i see how connection is immediately dropped and notebook contact goes offline in the roster of another Spark running on a PC.

Hello,

i cant still solve this problem…i have a 1000 clients running on defferent PC…and they still not notify that i got a broken socket connection…openfire server will not detect broken socket…my session on the server is still active…Please, if anyone out there how to solve this problem,please share some idea on how to resolve this…

HOW TO SETUP THE OPENFIRE SERVER THAT IT DETECTS BROKEN SOCKET CONNECTION (e.g Lost Internet connection or accidentally pull off the network cable)…

god bless u all!

Many thanks

glen

Glen, i’m not sure, but maybe Guuses patch for memory leak can affect this issue too, as he’s changing something about disconnecting idle clients. Though, maybe that’s not releated to broken connections. http://www.igniterealtime.org/issues/browse/OF-70

I can add, that while i wasnt able to reproduce this at home, at work though i’m seeing such behavior with laptops and Vista. When user unplugs LAN cable, Openfire doesnt notice this and still shows them online. If patch described above won’t change anything, then i’m afraid there are no other developer to look at this or try to fix (well, maybe one developer).

Well, it seem not to be related to Vista or laptops. I think this has to be something with network. When Openfire and clients are on the same switch (or in my home scenario, both server and client connected with one LAN cable), then it detects broken connection. If there are more switches in the way (2-4), then it becomes complicated and i have no knowlegde to test this more deeply. Maybe switches are still sending some stuck packets and Openfire “thinks” client is still connected As we will have more laptop users and probably a WiFi in future, this can become a frustrating problem for us too.

Hello wroot,

Thank you for the quick reply,im stuck with this problem over a month.it just that the server cannot detect client with broken connection…and the server did not drop automatically his session…do we have here a plugin to resolve this problem?

are u experiencing also this kind of problem?if yes,how do you solve?or you still find a solution regarding this kind of problem?

i read same problem here in the openfire forum but,i could not find an answer related to this problem.

Hoping soon that this problem would be resolve…

if anyone out here found a solution someday please,update me.i would greatly appreciated…

many thanks,

glen

Quick update. We have just tried to connect a client to the same switch where Openfire server is connected. And still the same problem. A bit later we will try to connect server and client to a newer “more sophisticated” switch. Will see if that changes anything.

wroot,

Yes,i think so,this is really very frustrating.i dont know what else i can do with this.if this is network related issue its a bad luck for me,because i have over a thousand of clients…and i need to update each clients whenever other clients got a broken connection…

i think the “openfire” would do this task to detect clients connected to him.and also openfire able to detect if the clients who connect to him get disconnected due to broken socket connection…

Hello wroot,

im looking forward on your testing.hope we can solve this problem so soon.good luck!

glen

I dont have good news for you, it made no difference what swithc we were using. I think it’s a problem in Openfire and a very long standing one (i have seen something similar 4 years ago). Unlucky, that there are not many active developers of Openfire now. So we may only hope, that Guus will fix that too somehow. I think i will file this as a separate ticket too.

OF-72

My clients are reporting me the same problem, and I name it ‘Ghostbuster mission’. It’s been impossible to manage.

Hello wroot,

Yes! definitely,all of this, was supposed to be handle by the openfire server.i also posted this problem in agsxmpp forum but,i think this problem is not anymore there concern…

agsxmpp forum said:

Because a XMPP session is one persistant TCP/IP connection you can’t notify the server of a broken connection. The server must detect the broken connection and log off the user.

Hoping this problem would be fix so soon.

Thanks,

glen

Hello again,

My tests werent correct after all. I forgot i have set xmpp.client.idle system property to -1 long time ago. This was causing that sessions were never disconnected because of idle. Today i have set it to 60000 (milliseconds, so it is 1 minute, default is 6 minutes). And now if i pull out the cable from my laptop, server will notice this after a 1 minute. So, it seems everything is fine with Openfire, at least in my environment. You can try settings it even smaller, so it would disconnect idle sessions quicker. But, if your client is not sending correct heartbeat packets ir will cause it to loose connection (server will assume the client is not here anymore and will disconnect it after a set timeout), then your clients will be constantly reconnecting. I wanted to avoid this, therefore i have set this property to -1, though it seems i dont need this. So far my clients are working fine. We are using Exodus, and also Spark is ok. Most of the clients should work fine i suppose.

I will have to close that bug ticket with Cannot Reproduce resolution. It can be reopened if there will be detailed bug report with reproduction steps.

Hello wroot,

its been a long time waiting for a solution of this problem but i don’t think xmpp.client.idle property would help me.because in my case i do checking client status if they are really online(or connected to the server).and this is very crucial in my case.so, i dont need to wait for a minute.before it detect that client is not anymore connected to the server.

Ex:How about if the client get disconnected.so,client session will drop after 1 minute…what if i check that client status in a middle of a minute…so, the server will says that client is still “ONLINE”.and we know that, is not…not reliable result.

if you have any idea bout this please do share and i would really appreciate it.

HAPPY NEW YEAR EVERYONE!

Many Thanks,

glen

1 Like

60000 is 60 secs, you can try smaller value, like 10000, 5000? 1? But as i said that can give you a side effect like your client could be reconnecting like a hell, because even if it sends a heartbeat, it can be possible it won’t be sending it that quick. If this is your custom client, you can probably modify it to send a heartbeat that quick, but i think this will have an impact on the server. 1000 clients sending a packet every milisecond to a server? Doesnt sound good.

A side topic. How do you imagine server to notice that a client was disconnected (not a normal log off then log off packets are sent to a server, but abruptedly plugged out). Client can’t send any notification to a server. Openfire is working by XMPP standards and waits for a idle timeout which admin has set. It waits for a heartbeat to come or not. Another way would be for server to poll information about the user every millisecond or so and then wait for an answer from it and then disconnect it if no answer comes in a millisec. But this would have the same huge impact on a server. It would be working mostly to just keep status correct, not for a messaging… To have such solution you will have to search for another software and also your client should be modified to understand such mechanics. I dont think Openfire will have such functionality by default. It is just a simple chatting server.

I thought you might be interested in this, Glen. There was a modification for the upcoming Openfire version done. OF-341, so now Openfire will ping clients after a half time of xmpp.client.idle value (if idle is 6 minutes, it will ping every 3 minutes, etc.). Client will have to respond or generate error response if it doesnt understand ping. Openfire will reset idle timeout if it receives answer or error message. Again, if you set idle timeout to say 10 secs, it will ping every client every 5 secs, which will create a bit of load on the server, though this ping command is very simple.

Hi wroot,

thanks for the buzz.i think this would be a great help to me.though, i need a bit more lower idle timeout.and i know it will create more load in the server if i set it in very low.but this would be a nice new feature in openfire.i will also play with it a little bit after a beta release…

additional question sir…why is it in other IM.(e.g YahooMesseger).if i LogOut other clients(e.g Your Friends or Roaster list) automatically received un available presence right away after you signout…i know this is a defferent topic but i am curious of what technology they used…

favor sir,could you buzz me again if you will be the first to test the new release.

thanks sir,

glen