Hi everyone,
Is there any feature available to check if a connection to the server is available? Something like sending Ping receiving Pong in IRC.
If Yes, is this an underwater feature or do we have to implement something around it?
Yours,
Mark Monster
Mark,
Try out the ConnectionListener feature. It allows you to register a listener that will be notifed anytime the connection is cloed (and will tell you why). Is that what you’'re looking for?
Regards,
Matt
I was just thinking sometimes it takes some time to get notices a connection is lost. For example I’'ve been chatting with a guy today after he pulled his network out, he still seemed to be online. Even 10 minutes later he still seemed to be online. Only after typing a message (so the client sends something to the server, …is typing a message), he got a connection failure.
I think it will be good, to regularly check the connection, with some stuff like ping/pong. When the server sends “pong” back you are sure the connection is kept.
I don’'t think this feature is in the ConnectionListener pack is it?
Regards,
Mark
Hi Mark,
The ConnectionListener is for monitoring the status of your connection to your server.
If the person you are chatting with goes offline, you should have received a “presence” update from the server notifying you when he went offline. If you didn’‘t get one, it may be the server didn’'t realize he was disconnected until it tried to send your message to him.
You really shouldn’‘t have to implement a ping feature for that reason as it’'s the servers responsibility to keep track of that and notify all subscribers of that users status. That being said, you could use an IQ “time” or “version” request on their client to see if they are alive (and get a pseudo ping time) if the client responds to those requests.
Were you and your chat partner on different servers or perhaps your chat partner was on a different transport (AIM/ICQ/MSN…etc)?
Take care,
John
Yes, it is hard for transports to detect dropped connections so the scenario that insurgent suggests is very likely if that is the case.
In general you’‘re at the mercy of the server for detecting when users go offline and become unreachable. And servers are at the mercy of tcp/ip which isn’‘t entirely reliably for quickly detecting dropped connections when data is not flowing between the end points (IM connections are idle a good portion of the time) or when bridging between networks (some IM protocols use a polling strategy where you simply can’'t detect someone has gone offline immediately).
If you really really need to know another user has gone offline at some particular point in time, using iq-time or iq-version is probably a good ping tactic. At least when chatting with other XMPP/Jabber clients that support those protocols. However, since not all clients support it, and very few transports will, it’'s not going to be ultra reliable in general and it will take up quite a bit of bandwidth.
I fear there is no clean solution to the problem. The XMPP/Jabber community has played with ping specific packets and other trickery and none have really been beneficial to overall performance. I think we have to continue to rely on servers to do the offline detection and notification…
-iain
If that’‘s the case. Maybe I shouldn’‘t build any support for transports in MyOwnMessenger. In that case, everybody can only use XMMP, but that won’'t be any trouble if everyone uses that ;).
I’'m going to think about this problem.
Regards,
Mark Monster
Ya, it is sad but true, current IM transports just is a poor solution. The reason is most other IM networks were not designed to have a s2s connection with other IM systems.
Despite the fact that an XMPP server supports transports on the server rather than client, the other networks only let you connect via a c2s connection. So a server transport means that not only does the server maintain a c2s connection from their local client to the server, but must also maintain another set of c2s connections; one for each IM system each user has a transport for. So if you have X users, and support 5 transports, you could theoretically have X5 + X(# xmpp resources connected) c2s connections - not very scalable.
Add to this the fact that most IM systems block any IP address from connecting more than a few times at once, blacklist connections that look like servers, and otherwise make transports hard to keep up and you have a pretty grim picture.
I do hope there is a good solution to the problem so I wish you the best on innovative solutions. In the end, I think the market will have to either go into a monopoly based on network size (aka AIM becoming the Microsoft of IM), or a standard s2s protocol will need to emerge. The two most likely are XMPP and SIMPLE. I of course would prefer XMPP but would take either if it would solve the problem.
-iain
In the end I think , we want every user to use XMPP, isn’'t this true?
Also I think you only should give every user a solution if it works for the full 100%. Else they will think XMPP is a bad protocol. Just because the problems occur using XMPP and Transports.
Yours,
Mark Monster
I disagree with you iain, I don’'t think IM transports is a bad solution.
A company which uses public IM only need to have the 5222 port open in the firewall and not one for each IM they want to use.
It want never be 5*X because not all users want to use all of the IM available, I have used lots of different IM systems over many years and currently I’‘m using only MSN,ICQ and XMPP. Maybe in the future I only would be available by XMPP and I think I’'m not alone.
Blacklist/blocking of IP addresses. I think managers of XMPP servers which support transports should make an agrement with the the other IM companies thus allowing these servers to connect multiple times.
Terje Pedersen - jid: senikk@jabber.org
- Blacklist/blocking of IP addresses. I think
managers of XMPP servers which support transports
should make an agrement with the the other IM
companies thus allowing these servers to connect
multiple times.
That would be nice, but reading the news lately, the following is true. Microsoft is going to ask money for connecting to their system. But that will be only for the builders. So will Trillian have to pay for a license, or else no one using Trillian will be allowed to connect to MSN Messenger. I don’'t think this will be only the problem Trillian has, also the connection through IM Transports will get troubles I think.
Regards,
Mark Monster
I disagree with you iain, I don’'t think IM transports
is a bad solution.
I would agree they were a good solution if they worked reliably.
- A company which uses public IM only need to have
the 5222 port open in the firewall and not one for
each IM they want to use.
Well, technically you still need to open the ports to the other IM systems but can filter content so it only goes to the server which is a lot more secure. I agree it’'s a big improvement though. The really BIG win for transports is the server serves as a choke point for all messages allowing you to enforce uniform auditing and other usage policies without having to resort to packet sniffing.
- It want never be 5*X because not all users want to
use all of the IM available, I have used lots of
different IM systems over many years and currently
I’'m using only MSN,ICQ and XMPP. Maybe in the future
I only would be available by XMPP and I think I’'m not
alone.
True. But scalability planning should be prepared for the eventuality to connecting to all supported transports. It’‘s been my experience that if it’'s easy and seemless for someone to be logged into multiple networks, they will.
- Blacklist/blocking of IP addresses. I think
managers of XMPP servers which support transports
should make an agrement with the the other IM
companies thus allowing these servers to connect
multiple times.
If that were possible it would certainly be the ideal solution. The most important network to transport to, AIM, currently does not offer that option.
-iain