Signalr從集線器外部呼叫特定客戶端

Question

我知道Chris Fulstow項目log4net.signalr ，如果您要使用非生產日志，因為它記錄了所有請求的所有消息，所以這是一個好主意。 我想通過發出請求來區分日志消息，然后將其發送回正確的瀏覽器。

這是我在追加程序中完成的操作：

 public class SignalRHubAppender:AppenderSkeleton
    {
        protected override void Append(log4net.Core.LoggingEvent loggingEvent)
        {
            if (HttpContext.Current != null)
            {
                var cookie = HttpContext.Current.Request.Cookies["log-id"];
                if (null != cookie)
                {
                    var formattedEvent = RenderLoggingEvent(loggingEvent);
                    var context = GlobalHost.ConnectionManager.GetHubContext<Log4NetHub>();
                    context.Clients[cookie.Value].onLog(new { Message = formattedEvent, Event = loggingEvent });
                }
            }
        }
    }

我正在嘗試將會話ID附加到cookie，但是由於cookie被覆蓋，因此無法在同一台計算機上使用。 這是我在客戶端上用於附加事件的代碼：

//start hubs
    $.connection.hub.start()
    .done(function () {
        console.log("hub subsystem running...");
        console.log("hub connection id=" + $.connection.hub.id);
        $.cookie("log-id", $.connection.hub.id);
        log4netHub.listen();
    });

結果，僅連接的最后一頁顯示日志消息。 我想知道是否有一些策略可以使來自當前請求的瀏覽器具有當前連接ID，如果有的話。 我也很想知道是否有更好的設計來實現每個瀏覽器的日志記錄。

編輯

我可以制作一個基於約定名稱的cookie（例如log-id-someguid），但是我想知道是否有更聰明的東西。

BOUNTY我決定開始對這個問題賞金，我會還詢問有關架構，為了看看我的策略是有道理，還是沒有。 我的疑問是，我正在從服務器到客戶端的單個“方向”上使用集線器，並且使用它來記錄不是源自對集線器的調用而是來自其他請求（可能是其他集線器上提出的請求）的活動。一個正確的方法，目標是瀏覽器可見的log4net附加程序？

Answer 1

即使在同一個SPA上打開多個選項卡時，如何正確定位正確的瀏覽器實例/選項卡的想法是通過Url區分它們。 一種實現的可能方法是在第一次訪問時將它們從http://foo.com重定向到http://foo.com/hhd83hd8hd8dh3 （每次隨機生成）。 URL重寫也可以通過其他方式完成，但這只是說明問題的一種方式。 這樣，附加程序將能夠檢查原始Url，並且通過保留在服務器端的某些映射從Url中可以標識正確的SignalR ConnectionId。 實現細節可能有所不同，但是基本思想就是這一點。 自第一個連接以來，您就可以跟蹤HttpContext中的更多可用信息，您也可以采用其他策略來防止任何劫持。

關於您的體系結構，我可以告訴您，這正是我在ElmahR中使用它的方式。 我有來自通知中心外部的消息（從其他Web應用程序發布的錯誤），並且向與該中心連接的所有客戶端（並訂閱了某些組）進行廣播：它工作正常。

我不是權威人士，但我也猜想，即使有多個集線器，這種架構也可以，因為一天結束時的集線器只是（一個）持久連接的抽象，允許您通過以下方式對消息進行分組上下文。 在幕后（我正在簡化），您只有一個持久的連接，來回傳遞消息，因此，無論您在其上定義的集線器結構（用來幫助您組織事物），都仍然堅持該連接，這樣就不會造成任何傷害。

SignalR擅長做兩件事：大規模廣播（客戶端）和一對一通信（呼叫者）。 只要您不嘗試做一些奇怪的事情，例如構建保持對特定調用者的服務器端引用，就可以了，無論有多少個集線器以及它們之間的交互。

這些是我的結論，來自實地。 也許您可以通過@dfowler詢問這個問題，看看他是否有（更）權威的准則。