locked
Which protocol? RRS feed

  • Question

  • I'm writing a solution for communication with a (.net) server. Now I'm thinking about a protocol I should use(Remoting, WebService, Sockets, ...). There are some things to consider:

    1. There may be many clients connecting to the server with that app (100000?)
    2. I want this app doesn't have any problems with routers (firewall, NAT)
    3. Later, there will be a C++ client (not managed)

    I'm tending to webservices because of (2,3) but don't know if there will be performance issues...

    What would you do?

    Konstantin

    Thursday, July 20, 2006 9:30 AM

Answers

  • Hi Konstantin,

    Remoting can work well over HTTP, so firewall issues will  not help you decide here.

    I dont think that there is a straightforward way to directly call .NET remoting services from unmanaged C++ clients. The interop stops at calling local methods - hence the path is usuall to call managed unmanaged C++ -> managed DLL -> .NET REMOTING. You might be able to find an implementation which implements a remoting clannel to work on this. But - you are going to have to use SOAP.

    Now from 2. and 3.  its given that you are going to use SOAP encoding, and you are going to go over HTTP.

    This leaves the point 1: Large number of clients. This give two considerations: Performance and Backward compatibility.

    - Performance: In my opinion, you are not going to see a difference whichever way you chose to go - requiring to parse and construct soap messages over HTTP protocol. If the performance is a key, you could consider either using HTTP post, or implement/find a lightweight interop library. In either case, you will have a serious limitation on the data-set you can pass across and could end up writing significant code to map that back to objects you need.

    - Backward compatibility: again there is nothing between the two communication methods to chose.

    So my  opinion will be to forget .NET remoting and either go for Web services , or look for an even lighter weight interop over HTTP ( like doing a HTTP post  -if the usage is very heavy and you have to count CPU cycles)..

    Pranshu

    Thursday, July 20, 2006 4:51 PM

All replies

  • Hi Konstantin,

    Remoting can work well over HTTP, so firewall issues will  not help you decide here.

    I dont think that there is a straightforward way to directly call .NET remoting services from unmanaged C++ clients. The interop stops at calling local methods - hence the path is usuall to call managed unmanaged C++ -> managed DLL -> .NET REMOTING. You might be able to find an implementation which implements a remoting clannel to work on this. But - you are going to have to use SOAP.

    Now from 2. and 3.  its given that you are going to use SOAP encoding, and you are going to go over HTTP.

    This leaves the point 1: Large number of clients. This give two considerations: Performance and Backward compatibility.

    - Performance: In my opinion, you are not going to see a difference whichever way you chose to go - requiring to parse and construct soap messages over HTTP protocol. If the performance is a key, you could consider either using HTTP post, or implement/find a lightweight interop library. In either case, you will have a serious limitation on the data-set you can pass across and could end up writing significant code to map that back to objects you need.

    - Backward compatibility: again there is nothing between the two communication methods to chose.

    So my  opinion will be to forget .NET remoting and either go for Web services , or look for an even lighter weight interop over HTTP ( like doing a HTTP post  -if the usage is very heavy and you have to count CPU cycles)..

    Pranshu

    Thursday, July 20, 2006 4:51 PM
  • Thank you, these are really good points to start with. I'm really tending to WS. And will keep an eye on system scalability in the feature..

    Thank you again

    Konstantin

     

    Thursday, July 20, 2006 7:00 PM
  • I had the same questions before.

    Web services won't work if you need bi-directional communication. If User A posts a message how you'll let the rest of the users to know??
    You can do this with polling but you get the performance hit.

    Personally, I chose sockets.

     

    Friday, July 21, 2006 1:48 PM
  • You may or may not have performance problems depending on many variables you did not specify e.g. regarding your point #1

    •  how will the clients interact with your system (how many concurrent users?
    • how many requests per second etc.)
    • does it have to be a single server that handles all the clients ?
    • do you have a central state that has to be managed or is it mostly read only?  does the server state can be partitioned to distribute the load etc
    • etc.

    other questions are about the messages themselves - do you need reliable messages? do you need transactional messages? do you need to acknowledge receipt ? do you need to postpone replies? do you need to publish to multiple clients? etc.

     

    As you said using web services it would be relatively easy to cover your points 2 & 3  another option is to use an ESB. most ESBs can expose web-service based end-points and support rich messaging capabilities

     

    Arnon

    Monday, July 24, 2006 4:05 PM
  • Hi ubercoder,

    Can you please give more details on this? Are you talking about HTTP Tunnelling ( rather HTTP(s) tunnelling ) so that you are able to make a socket connection thru a proxy server ?

    Or are you talking about some other method?

    In either case, can you please give some more details on the solution you are recommending?

    Pranshu

    Monday, July 24, 2006 4:11 PM
  • No, I don't support proxies at all.

    I chose bi-directional communication (sockets, TCP) from HTTP (no proxy issues) because my app needs it.

    Is a very crucial decision.
    With HTTP the only way to have a fake bi-di is via polling, but then you must take the performance hit.

    To my knowledge the only way to have the server communicate and fire events on the client is via sockets and TCP, which comes with proxy and NAT problems.

    Unless I'm wrong and I'll appreciate it if someone tells me otherwise.

    Ubercoder.

    Monday, July 24, 2006 4:20 PM
  •  ubercoder wrote:

    To my knowledge the only way to have the server communicate and fire events on the client is via sockets and TCP, which comes with proxy and NAT problems.

    Unless I'm wrong and I'll appreciate it if someone tells me otherwise.

    using messaging it isn't too much problem to have a message handler that will raise an event on the client side when an appropriate message arrives (been there, done that, got the t-shirt to prove it :) )

    Arnon

    Monday, July 24, 2006 4:30 PM
  • Arnon,

    Which technology you referring to???

    I'm eager to learn.

    My email is stefanos@hatedamnspammers-intermacro.com

     

    Monday, July 24, 2006 6:04 PM
  • Arnon,

    I'm still waiting to see that shirt 8-)

    What messaging technology can fire events on the client via HTTP?

     

     

    Wednesday, July 26, 2006 3:20 PM
  • Many messaging middlewares support that

     one example is SoniqMQ from SonicSoftware (www.sonicsoftware.com)

    Here is an excerpt from the documentation:

    • HTTP Direct Protocol Handlers - HTTP Direct is a broker-based set of properties and factories that enables seamless interfacing between the JMS message and HTTP document paradigms. Pure HTTP documents arriving inbound on SonicMQ broker ports are transformed into JMS messages for message production to the port's assigned destination. Outbound JMS messages to specified SonicMQ routing nodes are transformed to HTTP documents and then sent to the designated HTTP Web Server. HTTP Direct also has features to handle SOAP encoding and to read JMS properties from specified HTTP fields. See the SonicMQ Deployment Guide for more information and for samples of HTTP Direct.

    On the recieving side you can create a MessageListner to get an asynchronous call when a message arrives - something like:

    public class SampleConsumer : Sonic.Jms.MessageListener

    public void SampleListner()

    {

    Sonic.Jms.MessageConsumer subscriber =session.createConsumer(topic, String messageSelector);

    subscriber.setMessageListener(this); 

    .}

    //get an event when a message is recieved

    publicl void onMessage(Sonic.Jms.Message aMessage)

    {

     

    // Cast the message as a text message.

    Sonic.Jms.TextMessage textMessage = (Sonic.Jms.TextMessage) aMessage;

    }

    ...

    Wednesday, July 26, 2006 8:18 PM