将ASP.Net连接到Wcf / Tcp聊天服务

I have a WCF chat service that accepts duplex tcp connections. A single duplex tcp connection can be used to send and receive messages for more than one user (so I can have multiple chat servers that all connect to each other).

我有一个接受双工tcp连接的WCF聊天服务。单个双工tcp连接可用于为多个用户发送和接收消息(因此我可以拥有多个互相连接的聊天服务器)。

Now I want to add Web users into the mix, to let them chat with the desktop users. This is for a live-support type thing. Basically I'm trying to find out the best way to do "out of band" communications from ASP.Net to this chat service.

现在我想将Web用户添加到组合中,让他们与桌面用户聊天。这是一个实时支持型的东西。基本上我正试图找出从ASP.Net到这个聊天服务进行“带外”通信的最佳方式。

I was thinking that I could have a static/global duplex connection to one of the chat servers and I could use that for all requests to that ASP.Net server. Would this work? The duplex connection is ALL one-way calls, can I use this WCF channel without locking access to it?

我以为我可以与其中一个聊天服务器建立静态/全局双工连接,我可以将其用于对该ASP.Net服务器的所有请求。这会有用吗?双工连接是所有单向呼叫,我可以使用此WCF通道而无需锁定访问权限吗?

UPDATE: Thanks for your suggestions so far. I should have noted: My chat service is self-hosted, it's not running in IIS. So, I'm mainly concerned with how I can make IIS hold a connection open until the application unloads. The connection from web browser to IIS will be silverlight, flash, ajax, iframes, anything.

更新:感谢您的建议到目前为止。我应该注意到:我的聊天服务是自托管的,它不是在IIS中运行的。因此,我主要关注的是如何在应用程序卸载之前使IIS保持连接打开状态。从Web浏览器到IIS的连接将是silverlight,flash,ajax,iframe,任何东西。

3 个解决方案

#1

Your best bet is to implement a bi-directional message queue at the app level, indexing messages by a user and a session identifier. Then you could have the app level WCF service (aka peer) pop and push based on wait objects. Access to the queue will be need to be locked, but this is relatively low cost. WCF service will do the heavy lifting. At some point, though, I would expect the app to experience bottlenecks if only a single proxy is being used for sending messages. It seems to me that having a dedicated channel proxy per session might be more efficient, thereby keeping things less stateful. I would also allow for non-duplex connections, since all messages are one way operations.

最好的办法是在应用程序级别实现双向消息队列,由用户索引消息和会话标识符。然后你可以让应用程序级别的WCF服务(aka peer)基于等待对象弹出和推送。需要锁定对队列的访问,但这是相对较低的成本。 WCF服务将做繁重的工作。但是,在某些时候,如果只使用一个代理来发送消息,我希望应用程序能够遇到瓶颈。在我看来,每个会话拥有一个专用的通道代理可能会更有效,从而使事情变得更少有状态。我还允许非双工连接,因为所有消息都是单向操作。

#2

This may not answer you question, but you might be able to have silverlight do this and use similar code that your desktop version uses.

这可能无法回答您的问题,但您可以让silverlight执行此操作并使用您的桌面版使用的类似代码。

#3

One possibility to consider is to serve up a Silverlight 2 application as part of the ASP.NET page that the Web users navigate to.

要考虑的一种可能性是将Silverlight 2应用程序作为Web用户导航到的ASP.NET页面的一部分提供。

This Silverlight application could make use of the WCF Polling Duplex support in the System.ServiceModel.PollingDuplex.dll assemblies (one for Silverlight app one for WCF server) that come with the Silverlight 2 SDK.

此Silverlight应用程序可以使用Silverlight 2 SDK附带的System.ServiceModel.PollingDuplex.dll程序集(一个用于WCF服务器的Silverlight应用程序一个)中的WCF轮询双工支持。

I have a few blog posts and a sample application that demonstrate how to 'push' Stock updates from a Console Application that self-hosts a WCF service with two endpoints as follows:

我有一些博客文章和一个示例应用程序,演示如何从控制台应用程序“推送”库存更新,该应用程序使用两个端点自行托管WCF服务,如下所示:

using System;
using System.ServiceModel;
using System.ServiceModel.Description;

namespace StockServer
{
    public class StockServiceHost : ServiceHost
    {
        public StockServiceHost(object singletonInstance, params Uri[] baseAddresses)
            : base(singletonInstance, baseAddresses)
        {
        }

        public StockServiceHost(Type serviceType, params Uri[] baseAddresses)
            : base(serviceType, baseAddresses)
        {
        }

        protected override void InitializeRuntime()
        {
            this.AddServiceEndpoint(
                typeof(IPolicyProvider),
                new WebHttpBinding(),
                new Uri("http://localhost:10201/")).Behaviors.Add(new WebHttpBehavior());

            this.AddServiceEndpoint(
                typeof(IStockService),
                new PollingDuplexHttpBinding(),
                new Uri("http://localhost:10201/SilverlightStockService"));

            this.AddServiceEndpoint(
                typeof(IStockService),
                new WSDualHttpBinding(WSDualHttpSecurityMode.None),
                new Uri("http://localhost:10201/WpfStockService"));

            base.InitializeRuntime();
        }
    }
}

WPF clients connect to the WSDualHttpBinding endpoint and Silverlight clients connect to the PollingDuplexHttpBinding endpoint of the same WCF service. The app also shows how to handle the Silverlight client access policy requirements.

WPF客户端连接到WSDualHttpBinding端点,Silverlight客户端连接到同一WCF服务的PollingDuplexHttpBinding端点。该应用程序还显示了如何处理Silverlight客户端访问策略要求。

Clients (Silverlight or WPF) can add notes against a Stock in their UI and these notes propagate back to the server to be pushed to all other clients. This demonstrates communication in either direction and hopefully performs most of the necessary communication required for a chat application.

客户端(Silverlight或WPF)可以在其UI中添加针对Stock的注释,这些注释将传播回服务器以推送到所有其他客户端。这表明了在任一方向上的通信,并希望执行聊天应用程序所需的大部分必要通信。

You can see a screenshot of the demo application running here.

您可以在此处看到演示应用程序的屏幕截图。

#1

#2