Does Rails Support a Neat Way of Listening to a Udp Socket

How to listen UDP Sockets continously on a rails server

Rails really isn't designed for this. However you can start with the script in your question and make it a daemon with https://github.com/thuehlinger/daemons

Then talk to your Rails app via HTTP/API or alternatively directly to your database.

Where to place a socket within a rails app?

In rails files under config/initializers get loaded when the application starts.

So one way to do what you want is to create a new file there that initializes the socket connection and assign it to a constant which the rest of the application uses.

class Utility
  def self.socket_connection
    @connection ||= connect_socket
  end

  def self.connect_socket
    # Your logic for connecting the socket
  end
end

And later when you need the connection just use Utility.socket_connection

If this is "real" application, you probably need more sophisticated approach that:

• pools the connections to handle when different parts of the applications want to use socket connections at the same time. (They'd check out & in the connection, similarly how ActiveRecord's #with_connection works
• monitor the connections, closing and re-establishing them as necessary

Ruby - See if a port is open

Something like the following might work:

require 'socket'
require 'timeout'

def is_port_open?(ip, port)
  begin
    Timeout::timeout(1) do
      begin
        s = TCPSocket.new(ip, port)
        s.close
        return true
      rescue Errno::ECONNREFUSED, Errno::EHOSTUNREACH
        return false
      end
    end
  rescue Timeout::Error
  end

  return false
end

Puma Error: Cannot assign requested address - bind(2) for 10.0.2.2 port 3000 (Errno::EADDRNOTAVAIL)

Seems like you have 10.0.2.2 in your localhosts.

You can check it in /etc/hosts.

It may look like

...
127.0.0.1       localhost
10.0.2.2        localhost
...

If you don't need 10.0.2.2 here and you don't know why you got it (your case =)) you can remove this line and try to run rails s again.

Maybe you would have to restart your network system or you can reboot.

Another way would be running rails server on particular host like

rails s -b 127.0.0.1

I don't know exact reasons of the problem but I hope it helps you somehow.

Ruby Sockets: Error (EINVAL) while trying to bind a sending socket to a port

Getting EINVAL for bind() indicates that the address to bind to might still be in use.

To get around this

• either use a different address (ip-address and/or port)
• or if you are wanting to reuse a address, set the socket option SO_REUSEADDR on the socket prior to using it
• or do not bind ... ;-)

How to close TCP and UDP ports via windows command line

Yes, this is possible. You don't have to be the current process owning the socket to close it. Consider for a moment that the remote machine, the network card, the network cable, and your OS can all cause the socket to close.

Consider also that Fiddler and Desktop VPN software can insert themselves into the network stack and show you all your traffic or reroute all your traffic.

So all you really need is either for Windows to provide an API that allows this directly, or for someone to have written a program that operates somewhat like a VPN or Fiddler and gives you a way to close sockets that pass through it.

There is at least one program (CurrPorts) that does exactly this and I used it today for the purpose of closing specific sockets on a process that was started before CurrPorts was started. To do this you must run it as administrator, of course.

Note that it is probably not easily possible to cause a program to not listen on a port (well, it is possible but that capability is referred to as a firewall...), but I don't think that was being asked here. I believe the question is "how do I selectively close one active connection (socket) to the port my program is listening on?". The wording of the question is a bit off because a port number for the undesired inbound client connection is given and it was referred to as "port" but it's pretty clear that it was a reference to that one socket and not the listening port.

---

Related Topics