Necessidade de executar um servidor TCP, além de uma app Rails

Question

Eu tenho um Rails 2.0.2 aplicativo em execução com um db PostgreSQL. O aparelho recebe dados em uma porta TCP. Eu já codificado um rubi trabalhando multithreaded tcp servidor para receber os pedidos, mas eu preciso este código seja executado ao lado de meu aplicativo Rails.

Então, eu acho que eu preciso saber como para abranger um novo processo dentro Rails, ou como criar um segmento de trabalho que irá executar o meu ciclo servidor tcp rosca. Meu servidor tcp rubi poderia ter acesso a ActiveRecord, mas não é necessário (eu sempre pode criar uma solicitação HTTP, registrando os dados recebidos para o servidor Rails original)

Answer 1

coisas para quê complicar? Basta executar os aplicativos - o seu servidor TCP e as Rails aplicação -. Lado a lado

De qualquer puxar a camada de modelo (e ActiveRecord) em seu servidor TCP (SVN :: externos ou pistão pode funcionar bem para isso) e deixar a comunicação entre as duas aplicações acontecer através do banco de dados, ou permitir que o aplicativo Rails ser o " mestre" e se comunicar com ele via HTTP como você sugere.

Para ativar um aplicativo Ruby em um serviço do Windows, consulte a gema win32-service disponível a partir do projeto win32utils: http: //rubyforge.org/projects/win32utils/

Answer 2

Eu preciso do servidor TCP para ser executado como um serviço em um servidor Windows 2003. Eu uso o mongrel_service para carregar Rails como um serviço, e eu não sei de uma maneira de fazer o mesmo para o código Ruby puro. Se eu pudesse obter o meu servidor tcp começou quando o computador, vou olhar para a sua solução (que parece muito bom, no entanto).

Answer 3

Não faça seu app Rails responsável pelo estado do aplicativo de servidor TCP. Não é realmente muito bem adequada para fazer isso - e provavelmente não há razão para que eles precisam para ser iniciado em lock-passo absoluta uns com os outros. Use monit ou algo para monitorar ambos os processos do servidor.

É impossível dizer com certeza sem saber mais de sua arquitetura de aplicativo, mas eu sugiro usar ActiveRecord eo banco de dados para a comunicação entre os servidores em vez de HTTP. Desta forma, mesmo se o seu aplicativo Rails é baixo, por algum motivo, o outro servidor pode ainda processar os pedidos. Ele também vai provavelmente ser um pouco snappier.