2011-06-23 17 views
7

Tengo un servicio de WCF está alojado a través de TCP/IP (netTcpBinding):Mac (o C++) conexión con WCF binario

var baseWcfAddress = getWcfBaseUri(); 
host = new ServiceHost(wcfSingleton, baseWcfAddress); 

var throttlingBehavior = new System.ServiceModel.Description.ServiceThrottlingBehavior(); 
throttlingBehavior.MaxConcurrentCalls = Int32.MaxValue; 
throttlingBehavior.MaxConcurrentInstances = Int32.MaxValue; 
throttlingBehavior.MaxConcurrentSessions = Int32.MaxValue; 
host.Description.Behaviors.Add(throttlingBehavior); 

host.Open(); 

me gustaría escribir un cliente de Mac en Objective C o C++ . ¿Hay alguna clase existente que pueda facilitar la conexión a mi servicio WCF? Si no, ¿cuáles son mis pasos & opciones para hacerlo realidad?

+0

¿Cuál es el motivo para usar netTcpBinding? Puede que tenga algunas opciones adecuadas ... –

+0

'netTcpBinding' resultó ser una de las opciones más rápidas, ciertamente mucho más rápido que el enlace básico de BasicHttpBinding/WS que se probó. Esa es la única necesidad real ya que netTcpBinding usó texto binario versus texto directo, era más rápido. – bugfixr

+0

a la derecha; Lo sospeché mucho. Agregar una respuesta ... –

Respuesta

7

Se considera que no todas las encuadernaciones que comienzan con net son interoperables. Incluso el cliente .NET puro sin WCF no puede comunicarse con el servicio sin un esfuerzo enorme al volver a implementar todo el protocolo binario y la codificación. Probablemente debería comenzar con:

Su opción para Mac está utilizando Mono que debe tener soporte para netTcpBinding.

Su opción real para Objective-C/C++ en Mac es la creación de servicio WCF interoperable que expone datos a través de HTTP. Si no es el propietario del servicio, puede crear un servicio de enrutamiento WCF que será bridge entre HTTP y netTCP interoperables.

Editar:

Una cosa más - si el servicio utiliza netTcpBinding con la configuración por defecto que se asegura con la seguridad de Windows. Supongo que puede ser otro stopper en Mac.

0

En el contexto del comentario:

netTcpBinding resultó ser una de las opciones más rápidas - sin duda, mucho más rápido que el de vainilla BasicHttpBinding/WS vinculante que fue juzgado. Esa es la única necesidad real ya que netTcpBinding usó texto binario versus texto directo, era más rápido.

En primer lugar, he mirado esto muchas, muchas veces - y por extraño que parezca, cada vez que probarlo, NetTcpBinding falla por completo a ser cualquier más rápido que la oferta básica XML. Sin embargo, dado que el rendimiento es su objetivo, tengo opciones ...

Soy un poco parcial (desde que lo escribí), pero recomiendo "protobuf-net" aquí; ya que está diseñado con los mismos modismos que la mayoría de los serializadores .NET, es bastante fácil de intercambiar, pero es más rápido (CPU) y más pequeño (bandwitdh) en cada prueba que hago para esto - o prueba que other people make. Y como el formato protobuf es una especificación abierta, no tiene que preocuparse de que los enlaces "Net" no sean interoperables.

Para MS .NET, tengo ganchos WCF directos que pueden ser used purely from config haciendo que sea muy fácil. Honestamente, no sé qué tan bien funcionará con el equivalente Mono. No lo he intentado. Es podría funcionar, pero si no la otra opción es simplemente lanzar un byte[] o Stream a través de la red y preocuparse por la (de) serialización manualmente.

Mi diseño preferido aquí es basic-binding HTTP con MTOM habilitado, que le brinda la simplicidad y portabilidad del enlace xml más simple, sin la sobrecarga de base-64 para los datos binarios.

Cuestiones relacionadas