¿Debo usar WCF o conectores crudos?

Question

deseo de desarrollar una aplicación cliente-servidor en .NET que funciona de la siguiente manera:

1. Los clientes se conectan a un servidor central. El servidor necesita realizar un seguimiento de los clientes que se conectan, y debe permitir solo a los que conoce (tengo un repositorio de clientes permitidos). Esto se debe a que en mi aplicación, es fundamental saber quiénes están todos presentes en una instancia determinada.
2. Los clientes podrían conectarse a otros dispositivos, por ejemplo, a través de puertos LAN/USB/Serial. El servidor debería poder controlar estos dispositivos conectados a través del cliente. Por ejemplo, supongamos que el cliente está conectado a una cámara. El servidor debería poder encender la cámara en un momento determinado y luego recuperar las imágenes (o hacer que el cliente lo haga y subir el resultado al servidor).
3. También me gustaría la posibilidad de que estos clientes ejecuten ejecutables personalizados y obtengan el resultado. Por ejemplo, el servidor envía una aplicación (o invoca a algunas existentes) al cliente, hace que el cliente la ejecute y recupera los datos resultantes.

Me pregunto si puedo usar WCF para este propósito, o debería ir con buenos zócalos viejos. Aunque la red inicial sería pequeña, quiero que se escale (miles de clientes). Cualquier sugerencia sería muy apreciada.

Answer 1

Hoy nunca bajaría a un nivel tan bajo como enchufes a menos que realmente tengas que hacerlo. Trabajar con abstracciones de alto nivel es mucho más productivo y creativo. Mejor pasar 2-3 días aprendiendo WCF o .Net Remoting luego 2 semanas de depuración de cosas de bajo nivel.

Tuvimos una decisión similar a la de hace unas semanas. Decidimos usar Remoting, ya que puedes trabajar en el nivel de objeto, es muy fácil de configurar y bastante eficiente. Podríamos haber usado WCF, pero no fue tan simple de configurar.

La gran ventaja de Remoting o WCF es que puede pasar objetos entre el servidor y el cliente y llamar a métodos en cada lado.

Supongamos que usted ha escrito una abstracción para su cámara como:

class Camera 
{ 
    public CompressedImage GetFrame() 
    { 
     .... 
     return image; 
    } 
}  

continuación, puede crear un objeto remoto en el servidor y escribir algo como:

var cam = SomeClientObject.GetCamera(); //get proxy object for the cam 
.... 
var frame = cam.GetFrame(); 

que llamar al método GetFrame() en el cliente y le pasa la imagen a través de (inter) net, si la imagen es serializable. Lo único que debe tener en cuenta es qué objetos crean un proxy en el otro lado y qué objetos se copian en el otro lado.

Eso es realmente poderoso y funciona para nosotros como un encanto. Así que libere su mente de los sockets :)

Answer 2

Estoy de acuerdo Los enchufes son de muy bajo nivel, pero desde la descripción de su problema, parece que desea que el servidor inicie la comunicación con los clientes además del cliente habitual -> comunicación del servidor (es decir, iniciado por el cliente). También soy nuevo en WCF y sé que WCF admite la comunicación dúplex. Pero mi GUESS es que cuando un cliente realiza una solicitud también pasa una función de devolución de llamada a la que el servidor puede recurrir. Entonces, el modelo sigue siendo cliente -> servidor seguido de un servidor que llama a la devolución de llamada.

La comunicación iniciada por el servidor con WCF es algo que no soy aware de. Así que es posible que desee comprobar esto antes de decidir sobre cualquiera de los dos.
También podría considerar una combinación de ambos, como en, WCF para la mayoría de los escenarios y una gestión de subprocesos separada para la comunicación de socket para aquellos casos en que WCF no es adecuado/posible.

Gracias
VM

Answer 3

Puede usar WCF. Le permite hacer devoluciones de llamada al cliente. comience aquí: http://idunno.org/archive/2008/05/29/wcf-callbacks-a-beginners-guide.aspx

Y también estoy de acuerdo con otra respuesta: es mucho más productivo pasar unos días en la evaluación WCF en lugar de ir a sockets. En el futuro, necesitará obtener muchas funciones ausentes en el socket ... por lo que deberá implementarlas usted mismo. Mientras que WCF los proporciona fuera de la caja.

Answer 4

He estado haciendo exactamente lo mismo. Escribí un servidor basado en TCP que puede manejar 1,000 conexiones simultáneas de clientes con facilidad en aproximadamente una hora y culmina en 80 líneas de código. Pasé varios días intentando y fracasando en obtener un servidor WCF dúplex para hacer lo mismo. Se necesitaron 175 líneas de código para que un servidor WCF dúplex y el cliente funcionaran y se bloquea si 30 clientes intentan conectarse simultáneamente.

Así que no estoy de acuerdo con las otras respuestas aquí: He encontrado que WCF es un desastre absoluto y las tomas de corriente crudas son mucho más fáciles y confiables.