EventMachine::ConnectionError Exception: unable to resolve server address

[roots-ai]

Hi! I am following the basic given example for blather..

but I am getting this error

EventMachine::ConnectionError Exception: unable to resolve server address

on execution of client.run in the code below and the server shuts down..

Here is the config/initialisers/xmpp.rb

require 'blather/client/dsl'

module App
  extend Blather::DSL

  def self.run
    EM.run { client.run }
  end

  setup 'echo@jabber.local', 'echo'

  # Auto approve subscription requests
  subscription :request? do |s|
    write_to_stream s.approve!
  end

  # Echo back what was said
  message :chat?, :body do |m|
    write_to_stream m.reply
  end
end

trap(:INT) { EM.stop }
trap(:TERM) { EM.stop }

Thread.new { App.run }

While I am running the Eventmachine server by (which I runs well when I check and run telnet localhost 8081) ruby app/helpers/echo_server.rb

require 'eventmachine'

 module EchoServer
   def post_init
     puts "-- someone connected to the echo server!"
   end

   def receive_data data
     send_data ">>>test: #{data}"
     close_connection if data =~ /quit/i
   end

   def unbind
     puts "-- someone disconnected from the echo server!"
   end
end



EventMachine.run {
  EventMachine.start_server "127.0.0.1", 8081, EchoServer
  puts "Listening..."
}

What all am I doing wrong...
Can you please help me out?

[benlangfeld]

So, first question is why are you testing against this EventMachine server? It's clearly not a competent XMPP server.

Secondly, I'd say the reason for the exception is fairly clear. You've tried to login to 'echo@jabber.local'. The usual XMPP rules are followed for locating the server to connect to. First, Blather looks up SRV records from the domain part of the JID, and uses those if it finds them (which could include your custom server port of 8081, which is not the standard port for an XMPP server to use). If no SRV records are found, it will attempt a connection using the A record matching the domain part of the JID on the standard port (5222). In this case, your system resolver can't provide an IP address for jabber.local, and this is precisely what the exception is telling you.

[roots-ai]

Hi, Thanks for the answer. It makes some sense now. I am new to xmpp and blather. I made wrong conclusions when I read Em.run in the example, which I still don't know why it's there.

I directly started reading about blather, I think I need to know about xmpp first.. Will it be possible for you to guide me with what to be read to make a real-time app running with blather?

Thanks

[benlangfeld]

EM.run is required because Blather has to run inside of an EventMachine loop, which it leaves you to start for yourself, because you may want to run other things inside that loop also.

I can't give you any advice about your app because I don't know what your goals are. What do you mean "a real-time app"?

[roots-ai]

I want to create a facebook-ticker like feature using blather.

[benlangfeld]

I have no idea what a Facebook ticker is, sorry.

[roots-ai]

This is what a facebook-ticker is http://i.t1n.se/2011/facebook-ticker-400x209.png. Please let me know if you can relate to it.

Like facebook-ticker I want a user interactions on the website to be displayed in his friend circle (in close to real time).

[bklang]

@bhuwan-arora I think you've got the wrong idea. This doesn't look like the kind of thing XMPP was designed to do. XMPP is a chat protocol - like Google Chat, AOL Instant Messenger, MSN Messenger, etc. It shares chat messages and presence information in real-time. You can use XMPP to build chat applications in a web interface (like Facebook Chat), but it's not designed for a timeline of historical events at all.

[lpradovera]

What's wrong with AJAX? It looks like that is your use case.

[roots-ai]

@bklang I too haven't seen implementation of real-time-notifications using xmpp anywhere. But I guess both chat and real-time-notifications are executing the same kind of task, i.e. a server is listening for requests and whenever a new request is heard, it is delivered to the client. What's the difference between the two then..Please tell me where I am wrong?

@polysics If I go with AJAX then I will have to do something like short polling or long polling. Which I have read are outdated. I guess you meant suggesting me polling only..

[bklang]

@bhuwan-arora It's not that you can't use XMPP for this, it's that you shouldn't use XMPP for this (at least, not only for this). XMPP provides a host of things that it sounds like you don't need or care about (presence, typing notifications, multi-user chat) and it requires an external service to be running (ejabberd, for instance). These things are great, but if you don't need them, it's just extra complexity. All you really want is a browser push mechanism and a storage system. There are dozens of ways to do achieve what you want that are simpler and don't require a dedicated network service to be running. It's about choosing the right tool for the job.

[roots-ai]

@bklang Thanks, I got your point. This cleared a lot of confusion and saved a lot of time for me.

[benlangfeld]

@bklang Your argument is a simplification of XMPP, and is not correct. There's a bunch of material around about this (eg http://vimeo.com/41172502). XMPP is perfectly suited for these things (in this case, pubsub), especially since YAGNI almost certainly doesn't apply to this situation - extra features are almost certainly going to be added to some anorexic implementation until you've reinvented the last 15 years of work on XMPP. Don't do this, it's bad.

@bhuwan-arora Be aware that XMPP in the browser means one of two things: BOSH (long polling, XMPP over HTTP) or XMPP over WebSockets.

My intent is not to patronise or dissuade, but if your reasoning on this subject amounts to "I have read these things are out-dated", then I'm thinking maybe you should seek help from someone experienced in building these kinds of systems.

[roots-ai]

@benlangfeld "I am very much new to xmpp" and I am saying all this with the limited experience. I will read about this more. Thanks a lot for clarifying.