Which protocol?

Which protocol?

• Advectus

  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

  
  
  

• rabbitoh

  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;

  }

  ...

  
  
  

• DanSem1

  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

  
  
  

• Rhubarb

  Arnon,

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

  What messaging technology can fire events on the client via HTTP

  
  

• vtortola

  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

  
  
  

• Brandon Bloom

  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.

  
  

• pmak

  Arnon,

  Which technology you referring to

  I'm eager to learn.

  My email is stefanos@hatedamnspammers-intermacro.com

  
  

• OutrightLie

  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.

  
  

• My Vizai

  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

  
  
  

• mschelstrate

  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

  
  
  
• Which protocol?