locked
Design pattern for interactive communications between users RRS feed

  • Question

  • We have a need for two users to communicate interactively over a VPN connection through a DMZ.

    We are considering a smart client (internet side) talking to a web server (in the DMZ) talking to a smart client (within our network).

    Wondered if anyone knew of a design pattern (or any other solution) to this problem.

     

    Wednesday, February 22, 2006 2:44 PM

Answers

  • There are a few ...

    Out of curiosity, you mention that your were intending to use the web server. By this I am assuming you mean to use HTTP as your transport mechanism. The HTTP transport mechanism would offer one huge downfall .. you would have to poll for new messages which would greatly limit your scalability. Do you actually mean to use HTTP?

    Another option you may want to look to keep the relative simplicity of HTTP is to use remoting with events (although there are some security drawbacks to this). It is a simpler anser than creating a TCP/UDP based protocol and will be nearly as effective.

    If this is a largely scalable application that you wish to spend the time to do it the best way possible, direct messaging (or in your case middle man routing) is the best way to go. I would probably use UDP combined with MSNs (Message Sequence Numbers) if this were a serious application that there was a significant use for (i.e. a large scale chat system) TCP otherwise.

    http://www.developer.com/net/vb/article.php/3452471 is an example of remoting events in VB.NET, you will notice in your testing that by default remoting will use another socket for events .. there is a way around this using http://genuinechannels.com/ (a commercial product that also includes shared memory channels and other nifty things)

    Cheers,

    Greg

    Tuesday, February 28, 2006 8:19 AM

All replies

  • Well there's always peer to peer Instant messaging solutions (IM). you can enhance the security of such solutions using tools like the following http://www.ccl.co.uk/FaceTime.html

    Arnon

    Wednesday, February 22, 2006 10:23 PM
  • There are a few ...

    Out of curiosity, you mention that your were intending to use the web server. By this I am assuming you mean to use HTTP as your transport mechanism. The HTTP transport mechanism would offer one huge downfall .. you would have to poll for new messages which would greatly limit your scalability. Do you actually mean to use HTTP?

    Another option you may want to look to keep the relative simplicity of HTTP is to use remoting with events (although there are some security drawbacks to this). It is a simpler anser than creating a TCP/UDP based protocol and will be nearly as effective.

    If this is a largely scalable application that you wish to spend the time to do it the best way possible, direct messaging (or in your case middle man routing) is the best way to go. I would probably use UDP combined with MSNs (Message Sequence Numbers) if this were a serious application that there was a significant use for (i.e. a large scale chat system) TCP otherwise.

    http://www.developer.com/net/vb/article.php/3452471 is an example of remoting events in VB.NET, you will notice in your testing that by default remoting will use another socket for events .. there is a way around this using http://genuinechannels.com/ (a commercial product that also includes shared memory channels and other nifty things)

    Cheers,

    Greg

    Tuesday, February 28, 2006 8:19 AM
  • Greg,

    I'm building a similar win app and I'm thinking of using the "middle man routing" scenario as you call it.
    Clients will connect to the server via the internet and when one sends a message the server will forward it to all connected users.

    My question is why should I use .NET remoting?

    I'm thinking of using plain sockets using nSoftware's IPWorks components and exchange custom protocol-typed messages, which will be interpreted at each client and passed to my business objects.

    What do you think???

     

     

     

    Sunday, March 5, 2006 11:08 PM
  • As I said it would depend on the scale of your app.

    I could get a basic remoting based system up and running in a few hours though it is not as scalable as the plain socket methodology.

    Writing a socket server is not that difficult; but if you have not done it before it can be a daunting task. If you are comfortable going that route (or need the scalability) it is definately a better methodology.

    Greg

    Sunday, March 5, 2006 11:11 PM
  • Wow, thi is a fast reply, thanks.

    I ended up choosing sockets because remoting is too complicated for me at this point, and is not supporting bi-di behind firewalls.

    Talking about scalability:

    How do you think should I build my servers??
    I'm thinking of having a communication server where all socket connections will be and this is the server the client communicate with. This server then communicates to the business server(s) via remoting and pass the messages from the clients. This server(s) then decide what should happen next and command the comm. server to forward the messages to the right clients.

    My question is how to do load balancing the easy way so the comm. servers can choose the less working business server??? I know about Aplication Center Server but I'm not sure if I can handle it..

     

     

    Sunday, March 5, 2006 11:18 PM
  • I am just curious here.

     

    how many connections are you talking about supporting? a few hundred? 1000? 10000? 100000?

     

    Sunday, March 5, 2006 11:37 PM
  • Gregg,

    I'm talking about thousands of connections, maybe 5,000-10,000 at the beggining.
    As I get more users I'll add more servers.

    I beleivbe I van get around 1,000-2,000 soclets per server. But I believe I need less business servers than comm servers.

    Sunday, March 5, 2006 11:42 PM
  • now the messaging ... are the business servers independent of one another or do they require synchronization?

     

    also with this number of connections, UDP may be preferred.

     

     

    Monday, March 6, 2006 12:47 AM
  • What do you mean by synchronization? Do you mean caching??? i don't know what to use there either.  I must use some kind of caching because there will be a lot of load for the DB server.

    I'm thinking to use UDP for the chat, but not for the main functions of the app. I want to make sure data are passed.

    Monday, March 6, 2006 12:51 AM
  • You can do reliable data transport over UDP; you do not need to use TCP, TCP just provides it by default where as UDP does not. RDP2 is agreat example of such a protocol. You can see similar behaviors in other protocols such as TFTP which reliably (at completion) moves a file. The reason UDP is often preferred is that it is connectionless. The server that may have supported 1000 TCP socket can likely support many more UDP based clients (with much simpler code).

    Busines servers....

    What I mean is if I have 12 business servers that need to be synchronized with each other (i.e. a change is made to server 1 that change must be propagated to server 5) can be a big design problem as it can get quite complex to do tasks like this. It also can cause all sorts of neat race conditions that can pop up if you try to do it asynchronously.

    example of race condition.

    client 1 sends message ... gets forwarded to business server 3 which processes it and returns ...

    in the background, business server 3 goes to update the other business servers with this message.

    client 1 sends another message which is depedent upon the first message. It goes to server 7 which has not yet received the synchronization from server 3 about the first message.

    Server 7 is unable to process the message.

     

    So the question boils down to whether these servers can operate independently of each other or if their data is actually being synchronized as if it is being synchronized between them, there is alot of work to be performed there as well.

    Greg

    Monday, March 6, 2006 1:01 AM
  • I'm thinking of using the database for that or an indepented cahe server for faster times.

    Each business server gets/sets data in the cache server or database directly so there's no need to be synchronized.

    Is that a good desing???

    What you suggesting about tools?? I'm thinking of using IPWorks from nSoftware and not the default sockets from .Net 1.1.

    Is RDP2 available in .Net??

    Gregg, you being a great help to me so far and I apreciate that.

     

     

    Monday, March 6, 2006 1:07 AM
  • Sorry for the delay in response.

    The issue with scalability is going to come down to whereever your single point is, I was thinking business servers but you are just delegating the task to another server (cache/db). There are alot fo tricks one can use with a db (such as replication) but these all have their own issues. Also how are your notifications going to work back to the clients? This is a case where UDP would actually be alot easier as you could have a single server sending all messages as opposed to having to route the request to the proper communications server that had the TCP socket connected. Protocols based upon UDP do also have issues (especially with firewalls) which should be considerred if this is a public app; a common solution is to use UPNP to integrate with the router/firewall.

     

    As for RDP2 ... I am unaware of a pre-done library for it but it is a fairly simple protocol.

    http://www.faqs.org/rfcs/rfc1151.html

    Cheers,

    Greg

    Tuesday, March 7, 2006 9:02 PM
  • Greg,

    I changed my design a bit..Now clients "talk" to a Communication\Bussiness Server assign to them during login. These CBS server pass all requests to a controller server that holds all game data in a cache and periodically flush it to the database. So the controller is the single point and the database second.

    About nitifications; all players in the same tables will connect to the same CBS so, all messages leave from the same server.

    The only problem I want to solve is the firewal\NAts issues with sockets and TCP. they same of course applies to remoting too. Only web services don't have this problem but web services are one way calls..Unless I use polling...

    Tuesday, March 14, 2006 3:10 PM
  • Ok that seems to make some sense with all players at the same table being on the same server to reduce complexity; but what happens if you lose that server (just bringing up some scenarios) will the controller automatically move all of the players to another server upon reconnect? How will the controller know that the original server is dead.  Another question along the same line, what about a player who is on multiple tables (not sure if you support this or not).

    As for firewall issues; so long as you only open a connection from the client to the server and never vice versa you should not have an issue (except for people who have outgoing TCP connections banned but there is nothing you can do there).

    Greg

    Tuesday, March 14, 2006 6:55 PM
  • You brought a very good point.
    I may have to implement a ping mechanism from the controller to the business server. The controller holds all game data so it's easy to assing the table to another server.
    Business server work in a software round hobin load balancing.

    I have a backup game controller in case I lost the primary and it can get the data from the database to make it primary. In case I lost the datbase I'm screwed. 8-) I have a backup database too but is gonna be updated daily.

    Players can attend only one table.

    The client initiates the connection always and the socket stays open. Now the client can send messages to the server and vice versa.

    Tuesday, March 14, 2006 7:52 PM
  • "

    The client initiates the connection always and the socket stays open. Now the client can send messages to the server and vice versa."

    yes this is the key ... outgoing only from client..

    Wednesday, March 15, 2006 8:19 PM