Silverlight client - problems connecting with basic test

Mar 2, 2012 at 5:08 AM

Greetings,

First, I'd like to say a big 'thank you' to kerryjiang for the work on supersocket and related tools :)

I'm having problems getting a very basic silverlight client test to work using WebSocket4Net.

I am fairly certain my server is set up correctly (including clientaccesspolicy etc) because I am able to get a simple example working using the microsoft labs library via this code:

 

            ws = new System.ServiceModel.WebSockets.WebSocket("ws://192.168.174.130:4510/", "", "echo-protocol");

            ws.OnOpen += new EventHandler<EventArgs>(ws_OnOpen);
            ws.OnData += new EventHandler<System.ServiceModel.WebSockets.WebSocketEventArgs>(ws_OnData);

            ws.Open();

It works without any problems.  I would prefer to use WebSocket4Net (more features, continuing development, etc)

 

Here is my code using WebSocket4Net:

 

            websocket = new WebSocket("ws://192.168.174.130:4510/", "echo-protocol", WebSocketVersion.Rfc6455);
            

            websocket.Opened += websocket_Opened;
            websocket.Error += websocket_Error;
            websocket.Closed += websocket_Closed;
            websocket.MessageReceived += websocket_MessageReceived;
            websocket.Open();

But the connection fails and I receive the following error

{System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions.}
What could the problem be?

 

 

{System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions.}
Mar 2, 2012 at 5:14 AM

Some more information if it helps, here is the stack trace:

   at SLWebSockets.MainPage.websocket_Error(Object sender, ErrorEventArgs e)
   at WebSocket4Net.WebSocket.OnError(ErrorEventArgs e)
   at WebSocket4Net.WebSocket.client_Error(Object sender, ErrorEventArgs e)
   at SuperSocket.ClientEngine.ClientSession.OnError(Exception e)
   at SuperSocket.ClientEngine.TcpClientSession.ProcessConnect(SocketAsyncEventArgs e)
   at SuperSocket.ClientEngine.AsyncTcpSession.SocketEventArgsCompleted(Object sender, SocketAsyncEventArgs e)
   at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted(SocketAsyncEventArgs e)
   at System.Net.Sockets.SocketAsyncEventArgs.FinishOperationAsyncFailure(Exception exception, Int32 bytesTransferred, SocketFlags flags)
   at System.Net.Sockets.Socket.PolicyCheckCompleteCallback(SocketPolicyAsyncResult result)
   at System.Net.Sockets.SocketPolicyAsyncResult.Complete()
   at System.Net.Sockets.CrossDomainSocketPolicyManager.DoPolicyCheck(SocketPolicyAsyncResult result)
   at System.Net.Sockets.SocketPolicyDownloader.DownloadCallback()
   at System.Net.Sockets.TcpPolicyDownloaderProtocol.FinishOperation()
   at System.Net.Sockets.TcpPolicyDownloaderProtocol.SocketCallback(Object sender, SocketAsyncEventArgs args)
   at System.Net.Sockets.TcpPolicyDownloaderProtocolCallbacks.SocketCallback(Object sender, SocketAsyncEventArgs e)
   at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted(SocketAsyncEventArgs e)
   at System.Net.Sockets.SocketAsyncEventArgs.FinishOperationAsyncFailure(SocketError socketError, Int32 bytesTransferred, SocketFlags flags)
   at System.Net.Sockets.SocketAsyncEventArgs.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

It looks like it's failing to download the policy?   Note that using fiddler, I don't see an actual request being made when WebSocket4Net is attempting (but I do see the request when I use the microsoft library).

Coordinator
Mar 2, 2012 at 5:57 AM

I think Fidler cannot track raw socket request(NO-HTTP), the policy request may be sent throw raw socket.

BTW, policy access is not controlled by WebSocket4Net or microsoft labs library, it is managed by Silverlight runtime.

Coordinator
Mar 2, 2012 at 6:17 AM

TCP policy server is required.

http://msdn.microsoft.com/en-us/library/system.net.sockets.socketasynceventargs.socketclientaccesspolicyprotocol(v=vs.96).aspx

In Silverlight 3 for a connection request using System.Net.Sockets to the site (cross-domain or site of origin), the Silverlight runtime tries to open a connection using TCP to a well-known port (port 943) on the target site. If a TCP connection can be established, the Silverlight runtime sends a special string to the server to request a Silverlight policy file for use by System.Net.Sockets. The Silverlight runtime then waits to receive a reply from the target site that contains a Silverlight policy file. If this Silverlight policy file is returned (even if there is an error in parsing the file), it is used as the policy file for that socket request and all subsequent requests to that target site for the entire session of the Silverlight application.

In Silverlight 4 for a connection request using System.Net.Sockets, an application can choose instead to retrieve the policy file via the HTTP protocol on TCP port 80 instead of the custom TCP protocol on port 943. The socket policy file can be stored in the same "clientaccesspolicy.xml" file at the root of the requested target domain that is used for cross-domain network access by the WebClient and HTTP classes in the System.Net namespace. This allows HTTP servers that are already running HTTP services to authorize socket connections from Silverlight applications without having to deploy a new TCP server service on the machine and open a port through a firewall for port 943.

It seems I'll expose this property to users:

SocketClientAccessPolicyProtocol

 

Coordinator
Mar 2, 2012 at 6:46 AM

I'll improve it in my tonight! Please be patient...

:)

Mar 2, 2012 at 6:57 AM

Thanks!! :)

Coordinator
Mar 2, 2012 at 10:09 AM

I have finished this change, your issue would be fixed after you upgrade your code.

Mar 2, 2012 at 5:17 PM

Hi Kerry,

I think this is great progress to the silverlight implementation!  But I think there is still some issue.

Can you verify I'm using the new property correctly? 

 

        private WebSocket _websocket;
        private void StartWebSocket4Net()
        {
            Debug.WriteLine("Starting websocket4net");
            _websocket = new WebSocket("ws://192.168.174.131:4510/", "echo-protocol", WebSocketVersion.Rfc6455);
            _websocket.ClientAccessPolicyProtocol = System.Net.Sockets.SocketClientAccessPolicyProtocol.Http;

            _websocket.Opened += websocket_Opened;
            _websocket.Error += websocket_Error;
            _websocket.Closed += websocket_Closed;
            _websocket.MessageReceived += websocket_MessageReceived;
            _websocket.Open();
        }
     

        void websocket_Error(object sender, ErrorEventArgs e)
        {
            Debug.WriteLine("Error :" + e.ToString());
        }

        void websocket_Closed(object sender, EventArgs e)
        {
            Debug.WriteLine("Connection closed.");
        }

        void websocket_MessageReceived(object sender, MessageReceivedEventArgs e)
        {
            Debug.WriteLine("Msg received: " + e.Message);
        }

        private void websocket_Opened(object sender, EventArgs e)
        {
            Debug.WriteLine("Connection opened - sending message.");
            _websocket.Send("Hello!");
        }

 

With this code, I can now see that the clientaccesspolicy is correctly getting downloaded.  There is also no longer any SocketException being thrown.

However, Nothing else happens either - none of the events are raised.   My output log looks like this:

Starting websocket4net
The thread '' (0x794) has exited with code 0 (0x0).

Is there something I can do to help debug this?

Thanks,
Shaun

Coordinator
Mar 3, 2012 at 1:04 AM
Which websocket server are you using? Could you trace the raw socket communications between client and server? Then I can diagnosis it.

Sent from my Windows Phone

From: itzlegend
Sent: 3/3/2012 2:17 AM
To: kerry-jiang@hotmail.com
Subject: Re: Silverlight client - problems connecting with basic test [websocket4net:346966]

From: itzlegend

Hi Kerry,

I think this is great progress to the silverlight implementation! But I think there is still some issue.

Can you verify I'm using the new property correctly?

        private WebSocket _websocket;
        private void StartWebSocket4Net()
        {
            Debug.WriteLine("Starting websocket4net");
            _websocket = new WebSocket("ws://192.168.174.131:4510/", "echo-protocol", WebSocketVersion.Rfc6455);
            _websocket.ClientAccessPolicyProtocol = System.Net.Sockets.SocketClientAccessPolicyProtocol.Http;

            _websocket.Opened += websocket_Opened;
            _websocket.Error += websocket_Error;
            _websocket.Closed += websocket_Closed;
            _websocket.MessageReceived += websocket_MessageReceived;
            _websocket.Open();
        }
     

        void websocket_Error(object sender, ErrorEventArgs e)
        {
            Debug.WriteLine("Error :" + e.ToString());
        }

        void websocket_Closed(object sender, EventArgs e)
        {
            Debug.WriteLine("Connection closed.");
        }

        void websocket_MessageReceived(object sender, MessageReceivedEventArgs e)
        {
            Debug.WriteLine("Msg received: " + e.Message);
        }

        private void websocket_Opened(object sender, EventArgs e)
        {
            Debug.WriteLine("Connection opened - sending message.");
            _websocket.Send("Hello!");
        }

With this code, I can now see that the clientaccesspolicy is correctly getting downloaded. There is also no longer any SocketException being thrown.

However, Nothing else happens either - none of the events are raised. My output log looks like this:

Starting websocket4net
The thread '' (0x794) has exited with code 0 (0x0).

Is there something I can do to help debug this?

Thanks,
Shaun

Mar 3, 2012 at 2:22 AM

Kerry,

This does not seem to work:

1) download source code
2) Run build.bat *note: i get errors during this related to windowsphone and mono project types being unsupported, however the silverlight binary is still created so I assume it is OK
3) reference websocket4net in new silverlight project, add code listed above in my post

I was trying to help debug the problem so I removed the WebSocket4Net dll, and added the actual source code projects to my solution (and referenced the projects)

After a bunch of reference changes etc I was eventually able to get it to work at one point - but it required me to not use the 'error' eventhandler because visual studio wasn't happy about acknowledging the ErrorEventArgs type (i.e. when referencing SuperSocket.ClientEngine)

So, I think it may be a problem with references and/or the build script - maybe related to the way you're merging your assemblies?

I am happy to provide a communications trace, but please let me know if this information is helpful first, as I feel we may be chasing a ghost if we go down that road.

To answer your other question: I am using node.js (websocket-node) on a linux machine for connecting.  Are you aware of any publicly exposed websocket servers which run over a port exposed by silverlight which I can test against?

Thanks,
Shaun

Mar 3, 2012 at 2:49 AM

Kerry,

It is actually possible that I actually fixed the problem in source code which is why I was able to get it working at one point.   I think there may be a bug in DraftHybi10Processor.cs:

 

#if SILVERLIGHT
            handshakeBuilder.AppendFormatWithCrCf("GET {0} HTTP/1.1", websocket.TargetUri.GetPathAndQuery());
#else
            handshakeBuilder.AppendFormatWithCrCf("GET {0} HTTP/1.1", websocket.TargetUri.PathAndQuery);
#endif

 

 

Given the following uri:  ws://40interop.ep.interop.msftlabs.com:4502/servicemodelsamples/chat.svc

The GetPathAndQuery() function actually returns  ":4502/servicemodelsamples/chat.svc".   This results in the following GET request in the handshaking:

 

- Http: Request, GET :4502/servicemodelsamples/chat.svc 
    Command: GET
  + URI: :4502/servicemodelsamples/chat.svc
    ProtocolVersion: HTTP/1.1
    Upgrade:  WebSocket
    Connection:  Upgrade
    Sec-WebSocket-Version:  13
    Sec-WebSocket-Key:  c1423
    Host:  40interop.ep.interop.msftlabs.com
    Origin:  40interop.ep.interop.msftlabs.com
    HeaderEnd: CRLF

 

 

Based on comparing to a working example (network sniffing while visiting http://40interop.ep.interop.msftlabs.com/html5/wschat.html) I believe what we *need* to be submitting is:

- Http: Request, GET /servicemodelsamples/chat.svc 
    Command: GET
  + URI: /servicemodelsamples/chat.svc
    ProtocolVersion: HTTP/1.1
    Upgrade:  WebSocket
    Connection:  Upgrade
    Host:  40interop.ep.interop.msftlabs.com:4502
    Origin:  http://tempuri
    HeaderEnd: CRLF

 

Also, perhaps it is an error that you are not including the port number in the "Host:" header. (:4502).

And would it make sense to allow us to specify a Origin?  I think this might be helpful in silverlight OOB applications :)

So, to recap, my current theory is:

  • All my referencing problems were more likely self-inflicted from when I was trying to add the source code to my solution for debugging (and possibly my failure to 'clean' my solution)
  • The only problems existing may be the protocol mismatch shown above

 

I hope this helps.

Thanks,
Shaun

Coordinator
Mar 3, 2012 at 3:34 AM
Great, you are the man, you helped me find the bug. I'll fix it ASAP.

Sent from my Windows Phone

From: itzlegend
Sent: 3/3/2012 11:49 AM
To: kerry-jiang@hotmail.com
Subject: Re: Silverlight client - problems connecting with basic test [websocket4net:346966]

From: itzlegend

Kerry,

It is actually possible that I actually fixed the problem in source code which is why I was able to get it working at one point. I think there may be a bug in DraftHybi10Processor.cs:

#if SILVERLIGHT
            handshakeBuilder.AppendFormatWithCrCf("GET {0} HTTP/1.1", websocket.TargetUri.GetPathAndQuery());
#else
            handshakeBuilder.AppendFormatWithCrCf("GET {0} HTTP/1.1", websocket.TargetUri.PathAndQuery);
#endif

Given the following uri: ws://40interop.ep.interop.msftlabs.com:4502/servicemodelsamples/chat.svc

The GetPathAndQuery() function actually returns ":4502/servicemodelsamples/chat.svc". This results in the following GET request in the handshaking:

- Http: Request, GET :4502/servicemodelsamples/chat.svc 
    Command: GET
  + URI: :4502/servicemodelsamples/chat.svc
    ProtocolVersion: HTTP/1.1
    Upgrade:  WebSocket
    Connection:  Upgrade
    Sec-WebSocket-Version:  13
    Sec-WebSocket-Key:  c1423
    Host:  40interop.ep.interop.msftlabs.com
    Origin:  40interop.ep.interop.msftlabs.com
    HeaderEnd: CRLF

Based on comparing to a working example (network sniffing while visiting http://40interop.ep.interop.msftlabs.com/html5/wschat.html) I believe what we *need* to be submitting is:

- Http: Request, GET /servicemodelsamples/chat.svc 
    Command: GET
  + URI: /servicemodelsamples/chat.svc
    ProtocolVersion: HTTP/1.1
    Upgrade:  WebSocket
    Connection:  Upgrade
    Host:  40interop.ep.interop.msftlabs.com:4502
    Origin:  http://tempuri
    HeaderEnd: CRLF

Also, perhaps it is an error that you are not including the port number in the "Host:" header. (:4502).

And would it make sense to allow us to specify a Origin? I think this might be helpful in silverlight OOB applications :)

So, to recap, my current theory is:

  • All my referencing problems were more likely self-inflicted from when I was trying to add the source code to my solution for debugging (and possibly my failure to 'clean' my solution)
  • The only problems existing may be the protocol mismatch shown above

I hope this helps.

Thanks,
Shaun

Coordinator
Mar 3, 2012 at 12:34 PM

I think the latest change has been fixed your issue.

Mar 3, 2012 at 6:21 PM

Hi Kerry,

Woo it works! :)  I now have everything talking.

There may still be a need to include the port number in the 'Host' header as the microsoft labs service rejects the request without it ( it throws a fault of http://schemas.microsoft.com/ws/2006/05/framing/faults/EndpointNotFound).  I do not know if the MS labs service is wrong to require it, or if you need to add it...

Thanks so much for your hard work on this! 

Coordinator
Mar 4, 2012 at 2:07 AM
I'LL compare with other browsers!

Sent from my Windows Phone

From: itzlegend
Sent: 3/4/2012 3:21 AM
To: kerry-jiang@hotmail.com
Subject: Re: Silverlight client - problems connecting with basic test [websocket4net:346966]

From: itzlegend

Hi Kerry,

Woo it works! :) I now have everything talking.

There may still be a need to include the port number in the 'Host' header as the microsoft labs service rejects the request without it ( it throws a fault of http://schemas.microsoft.com/ws/2006/05/framing/faults/EndpointNotFound). I do not know if the MS labs service is wrong to require it, or if you need to add it...

Thanks so much for your hard work on this!

Coordinator
Mar 4, 2012 at 3:43 AM

Yes, you are correct! I'll fix it ASAP.

http://tools.ietf.org/html/rfc6455#section-1.3

4.   The request MUST contain a |Host| header field whose value
        contains /host/ plus optionally ":" followed by /port/ (when not
        using the default port).
Mar 4, 2012 at 4:33 AM
Edited Mar 4, 2012 at 4:57 AM

Thanks! :)   Everything is working well (I have silverlight talking to node.js server!)

One thing I notice though is that if I don't send any messages for 30 seconds, the connection is closed.  It seems to be consistent (always after 30 seconds of not sending a message), and I still get disconnected even if the server is sending me message.

I think the close is likely initiated by WebSocket4Net (or .Net itself) because I don't see this behavior from my other client (a node.js client).

Do you know what might cause that?

Thanks!
Shaun

 

Edit:  Random theory...  I think my server (websocket-node - https://github.com/Worlize/WebSocket-Node/wiki/Documentation )  Is using the 'keepalive' functionality of the websocket protocol.  Does WebSocket4Net respond to those pings?  Perhaps the server is disconnecting because it doesn't get a reply?

Coordinator
Mar 4, 2012 at 6:02 AM

I also found this issue before, but my keeping time was longer, so I implemented sending ping in a interval to keep connection alive.

And the client also can react with the server's ping.

I'll check this issue much further.

Mar 4, 2012 at 7:04 AM

I think I confirmed that theory... I set my websocket-node server to not disconnect on keep-alive timeout:

    var wsServer = new WebSocketServer({
        httpServer: server,
        autoAcceptConnections: false,
        dropConnectionOnKeepaliveTimeout : false
    });

and the connection now remains open :)

Coordinator
Mar 4, 2012 at 7:16 AM

Oh, I found I haven;t handle server's ping requests.

Thanks for your finding!

Mar 4, 2012 at 8:05 AM

No, thank you! :)

One more (maybe low priority) feature might be to acknowledge the 'close handshake' also.   From what i understand, the server sends a 'close frame' to the client, which the client should acknowledge.  Currently, WebSocket4Net (silverlight) does not acknowledge the close frame, so it takes a long time for the socket connection to actually close for servers which are obeying the close handshake.  (For example, by default, websocket-node waits 5 seconds for the acknowledge before closing the socket).

I mention this because I guess it's probably in the same code area as the ping-reply code so might be good to add that support at the same time :)

Thanks again for all your hard work!!!

Coordinator
Mar 4, 2012 at 8:11 AM

I am sure I had implemented the closing handshake. I missed Ping handling because I used client driven ping/pong keep alive.

Did you find some issue about it?

Coordinator
Mar 4, 2012 at 9:27 AM

I have submit the change which includes the ping reacting just now, could you have a try?

Mar 5, 2012 at 5:50 PM

Hi kerry.  I receive an error when the ping is handled:

Index was outside the bounds of the array.
   at System.Net.AlternativeMarshaller.UnsafeAddrOfPinnedArrayElement(Byte[] byteArray, Int32 offset)
   at System.Net.Sockets.SocketAsyncEventArgs.SetupOverlappedSingle(Boolean pinSingleBuffer)
   at System.Net.Sockets.SocketAsyncEventArgs.CheckPinSingleBuffer(Boolean pinUsersBuffer)
   at System.Net.Sockets.SocketAsyncEventArgs.SetBufferInternal(Byte[] buffer, Int32 offset, Int32 count)
   at System.Net.Sockets.SocketAsyncEventArgs.SetBuffer(Byte[] buffer, Int32 offset, Int32 count)
   at SuperSocket.ClientEngine.AsyncTcpSession.SendInternal(ArraySegment`1 segment)
   at SuperSocket.ClientEngine.TcpClientSession.DequeueSend()
   at SuperSocket.ClientEngine.AsyncTcpSession.Sending_Completed(Object sender, SocketAsyncEventArgs e)
   at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted(SocketAsyncEventArgs e)
   at System.Net.Sockets.SocketAsyncEventArgs.FinishOperationSuccess(SocketError socketError, Int32 bytesTransferred, SocketFlags flags)
   at System.Net.Sockets.SocketAsyncEventArgs.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

 

Thanks,
Shaun

Coordinator
Mar 6, 2012 at 5:23 AM

Hi Shaun,  I cannot produce it.

How can you produce it? Did you compile the latest source code fully? Could you send me a socket communication log between client and server?

Mar 8, 2012 at 1:41 AM

Can you tell me the best way to create this log?  I'm having difficulty getting network monitor to see communications - likely because my 'server' is a virtual machine on the same box (i guess it doesnt cross the network card).   Also, I'm not sure if this is what you mean by 'communication log'.

I will try to get the client on a different machine so that I can see communications with network monitor.

Coordinator
Mar 8, 2012 at 1:44 AM

Oh, it's easy for SuperWebSocket to log traffic, but I am not familiar with node.js or socket.io.

But you can run wiredshark on you local to trace traffic from client side.

 

BTW, could you try the latest code? I am not sure whether the latest fixes your issue.

Mar 8, 2012 at 1:52 AM

ok, i will try that first :) meanwhile I'm getting SL5 tools installed on another machine to test from there.  Maybe wiredshark can work, but i would guess it can also be fooled by VMWare virtual PC technology (some sort of fake network i guess)

Mar 8, 2012 at 2:43 AM

Hi Kerry,

I can report that keepalive is now working and there is no errors! :)  Great!!

The only thing that might be remaining is the close handshake.  My expectation is that when I call .close() on the server (websocket-node) the connection should close.  Instead, the server waits 5 sec. and then closes.  I'm not sure what to look for to determine why the close handshake isn't successful (resulting in the 5 sec timeout and force close).

I uploaded a network monitor capture file here if you want to look into it : http://www.filedropper.com/w4n

Note: 192.168.1.5 is the server, other is the client (websocket4net)

Coordinator
Mar 8, 2012 at 2:54 AM

Oh, could you debug into the code:

WebSocket4Net/Command/Close.cs, ExecuteCommand(xxx,xx)

I think the closing handshake response would be sent.

Coordinator
Mar 8, 2012 at 3:15 AM

Oh, I might find the issue, there might be an exception when send a handshake response.

Coordinator
Mar 8, 2012 at 3:22 AM

Could you get the latest source code and then verify the closing handshake bug?

 

Thank you for helping me fixed so many bugs!

Mar 8, 2012 at 3:49 AM

I really wouldnt don't know what to look for :)

Perhaps this trace can help:

No.     Time        Source                Destination           Protocol Length Info
     53 13.666890   192.168.1.17          192.168.1.5           TCP      66     31025 > 4510 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1

Frame 53: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: AsustekC_43:86:1b (00:1d:60:43:86:1b), Dst: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0)
Internet Protocol Version 4, Src: 192.168.1.17 (192.168.1.17), Dst: 192.168.1.5 (192.168.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 52
    Identification: 0x36f4 (14068)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x4069 (maybe caused by "IP checksum offload"?)]
    Source: 192.168.1.17 (192.168.1.17)
    Destination: 192.168.1.5 (192.168.1.5)
Transmission Control Protocol, Src Port: 31025 (31025), Dst Port: 4510 (4510), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     54 13.668375   192.168.1.5           192.168.1.17          TCP      66     4510 > 31025 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=16

Frame 54: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 52
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0xb75d [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 0, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     55 13.668410   192.168.1.17          192.168.1.5           TCP      54     31025 > 4510 [ACK] Seq=1 Ack=1 Win=65700 Len=0

Frame 55: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: AsustekC_43:86:1b (00:1d:60:43:86:1b), Dst: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0)
Internet Protocol Version 4, Src: 192.168.1.17 (192.168.1.17), Dst: 192.168.1.5 (192.168.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x36f5 (14069)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x4074 (maybe caused by "IP checksum offload"?)]
    Source: 192.168.1.17 (192.168.1.17)
    Destination: 192.168.1.5 (192.168.1.5)
Transmission Control Protocol, Src Port: 31025 (31025), Dst Port: 4510 (4510), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     56 13.684111   192.168.1.17          192.168.1.5           TCP      251    31025 > 4510 [PSH, ACK] Seq=1 Ack=1 Win=65700 Len=197

Frame 56: 251 bytes on wire (2008 bits), 251 bytes captured (2008 bits)
Ethernet II, Src: AsustekC_43:86:1b (00:1d:60:43:86:1b), Dst: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0)
Internet Protocol Version 4, Src: 192.168.1.17 (192.168.1.17), Dst: 192.168.1.5 (192.168.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 237
    Identification: 0x36f6 (14070)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x3fae (maybe caused by "IP checksum offload"?)]
    Source: 192.168.1.17 (192.168.1.17)
    Destination: 192.168.1.5 (192.168.1.5)
Transmission Control Protocol, Src Port: 31025 (31025), Dst Port: 4510 (4510), Seq: 1, Ack: 1, Len: 197
Data (197 bytes)

0000  47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a   GET / HTTP/1.1..
0010  55 70 67 72 61 64 65 3a 20 57 65 62 53 6f 63 6b   Upgrade: WebSock
0020  65 74 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20   et..Connection: 
0030  55 70 67 72 61 64 65 0d 0a 53 65 63 2d 57 65 62   Upgrade..Sec-Web
0040  53 6f 63 6b 65 74 2d 56 65 72 73 69 6f 6e 3a 20   Socket-Version: 
0050  31 33 0d 0a 53 65 63 2d 57 65 62 53 6f 63 6b 65   13..Sec-WebSocke
0060  74 2d 4b 65 79 3a 20 35 37 36 39 31 0d 0a 48 6f   t-Key: 57691..Ho
0070  73 74 3a 20 31 39 32 2e 31 36 38 2e 31 2e 35 3a   st: 192.168.1.5:
0080  34 35 31 30 0d 0a 4f 72 69 67 69 6e 3a 20 31 39   4510..Origin: 19
0090  32 2e 31 36 38 2e 31 2e 35 0d 0a 53 65 63 2d 57   2.168.1.5..Sec-W
00a0  65 62 53 6f 63 6b 65 74 2d 50 72 6f 74 6f 63 6f   ebSocket-Protoco
00b0  6c 3a 20 65 6e 66 75 73 65 70 72 6f 74 6f 63 6f   l: enfuseprotoco
00c0  6c 0d 0a 0d 0a                                    l....

No.     Time        Source                Destination           Protocol Length Info
     57 13.685539   192.168.1.5           192.168.1.17          TCP      60     4510 > 31025 [ACK] Seq=1 Ack=198 Win=15680 Len=0

Frame 57: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x76ec (30444)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x407d [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 1, Ack: 198, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     58 13.686493   192.168.1.5           192.168.1.17          TCP      244    4510 > 31025 [PSH, ACK] Seq=1 Ack=198 Win=15680 Len=190

Frame 58: 244 bytes on wire (1952 bits), 244 bytes captured (1952 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 230
    Identification: 0x76ed (30445)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x3fbe [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 1, Ack: 198, Len: 190
Data (190 bytes)

0000  48 54 54 50 2f 31 2e 31 20 31 30 31 20 53 77 69   HTTP/1.1 101 Swi
0010  74 63 68 69 6e 67 20 50 72 6f 74 6f 63 6f 6c 73   tching Protocols
0020  0d 0a 55 70 67 72 61 64 65 3a 20 77 65 62 73 6f   ..Upgrade: webso
0030  63 6b 65 74 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e   cket..Connection
0040  3a 20 55 70 67 72 61 64 65 0d 0a 53 65 63 2d 57   : Upgrade..Sec-W
0050  65 62 53 6f 63 6b 65 74 2d 41 63 63 65 70 74 3a   ebSocket-Accept:
0060  20 62 6b 77 5a 65 47 78 6a 68 43 45 74 38 67 63    bkwZeGxjhCEt8gc
0070  64 44 52 4f 45 58 2b 68 54 30 70 30 3d 0d 0a 53   dDROEX+hT0p0=..S
0080  65 63 2d 57 65 62 53 6f 63 6b 65 74 2d 50 72 6f   ec-WebSocket-Pro
0090  74 6f 63 6f 6c 3a 20 65 6e 66 75 73 65 70 72 6f   tocol: enfusepro
00a0  74 6f 63 6f 6c 0d 0a 4f 72 69 67 69 6e 3a 20 31   tocol..Origin: 1
00b0  39 32 2e 31 36 38 2e 31 2e 35 0d 0a 0d 0a         92.168.1.5....

No.     Time        Source                Destination           Protocol Length Info
     59 13.774949   192.168.1.17          192.168.1.5           TCP      60     31025 > 4510 [PSH, ACK] Seq=198 Ack=191 Win=65508 Len=6

Frame 59: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: AsustekC_43:86:1b (00:1d:60:43:86:1b), Dst: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0)
Internet Protocol Version 4, Src: 192.168.1.17 (192.168.1.17), Dst: 192.168.1.5 (192.168.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 46
    Identification: 0x36f7 (14071)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x406c (maybe caused by "IP checksum offload"?)]
    Source: 192.168.1.17 (192.168.1.17)
    Destination: 192.168.1.5 (192.168.1.5)
Transmission Control Protocol, Src Port: 31025 (31025), Dst Port: 4510 (4510), Seq: 198, Ack: 191, Len: 6
Data (6 bytes)

0000  81 d3 2a 36 87 60                                 ..*6.`

No.     Time        Source                Destination           Protocol Length Info
     60 13.815359   192.168.1.5           192.168.1.17          TCP      60     4510 > 31025 [ACK] Seq=191 Ack=204 Win=15680 Len=0

Frame 60: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x76ee (30446)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x407b [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 191, Ack: 204, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     61 13.815390   192.168.1.17          192.168.1.5           TCP      137    31025 > 4510 [PSH, ACK] Seq=204 Ack=191 Win=65508 Len=83

Frame 61: 137 bytes on wire (1096 bits), 137 bytes captured (1096 bits)
Ethernet II, Src: AsustekC_43:86:1b (00:1d:60:43:86:1b), Dst: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0)
Internet Protocol Version 4, Src: 192.168.1.17 (192.168.1.17), Dst: 192.168.1.5 (192.168.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 123
    Identification: 0x36f8 (14072)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x401e (maybe caused by "IP checksum offload"?)]
    Source: 192.168.1.17 (192.168.1.17)
    Destination: 192.168.1.5 (192.168.1.5)
Transmission Control Protocol, Src Port: 31025 (31025), Dst Port: 4510 (4510), Seq: 204, Ack: 191, Len: 83
Data (83 bytes)

0000  51 14 e4 0f 44 42 f5 0f 46 5a e2 12 08 0c a5 32   Q...DB..FZ.....2
0010  4f 57 eb 14 43 5b e2 42 06 14 e6 03 5e 5f e8 0e   OW..C[.B....^_..
0020  08 0c a5 33 5f 54 f4 03 58 5f e5 05 08 1a a5 04   ...3_T..X_......
0030  4b 42 e6 42 10 4d a5 07 4b 42 e2 17 4b 4f ce 04   KB.B.M..KB..KO..
0040  08 0c b6 50 1a 1a a5 03 5a 43 ce 04 08 0c b5 50   ...P....ZC.....P
0050  1a 4b fa                                          .K.

No.     Time        Source                Destination           Protocol Length Info
     62 13.816490   192.168.1.5           192.168.1.17          TCP      60     4510 > 31025 [ACK] Seq=191 Ack=287 Win=15680 Len=0

Frame 62: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x76ef (30447)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x407a [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 191, Ack: 287, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     63 13.818060   192.168.1.5           192.168.1.17          RELOAD Frame 127    ACK

Frame 63: 127 bytes on wire (1016 bits), 127 bytes captured (1016 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 113
    Identification: 0x76f0 (30448)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x4030 [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 191, Ack: 287, Len: 73
REsource LOcation And Discovery Framing: ACK

No.     Time        Source                Destination           Protocol Length Info
     64 13.818404   192.168.1.5           192.168.1.17          TCP      60     4510 > 31025 [PSH, ACK] Seq=264 Ack=287 Win=15680 Len=4

Frame 64: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 44
    Identification: 0x76f1 (30449)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x4074 [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 264, Ack: 287, Len: 4
Data (4 bytes)

0000  88 02 03 e8                                       ....

No.     Time        Source                Destination           Protocol Length Info
     65 13.818418   192.168.1.17          192.168.1.5           TCP      54     31025 > 4510 [ACK] Seq=287 Ack=268 Win=65432 Len=0

Frame 65: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: AsustekC_43:86:1b (00:1d:60:43:86:1b), Dst: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0)
Internet Protocol Version 4, Src: 192.168.1.17 (192.168.1.17), Dst: 192.168.1.5 (192.168.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x36f9 (14073)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x4070 (maybe caused by "IP checksum offload"?)]
    Source: 192.168.1.17 (192.168.1.17)
    Destination: 192.168.1.5 (192.168.1.5)
Transmission Control Protocol, Src Port: 31025 (31025), Dst Port: 4510 (4510), Seq: 287, Ack: 268, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     66 13.835047   192.168.1.17          192.168.1.5           TCP      60     31025 > 4510 [PSH, ACK] Seq=287 Ack=268 Win=65432 Len=6

Frame 66: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: AsustekC_43:86:1b (00:1d:60:43:86:1b), Dst: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0)
Internet Protocol Version 4, Src: 192.168.1.17 (192.168.1.17), Dst: 192.168.1.5 (192.168.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 46
    Identification: 0x36fa (14074)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x4069 (maybe caused by "IP checksum offload"?)]
    Source: 192.168.1.17 (192.168.1.17)
    Destination: 192.168.1.5 (192.168.1.5)
Transmission Control Protocol, Src Port: 31025 (31025), Dst Port: 4510 (4510), Seq: 287, Ack: 268, Len: 6
Data (6 bytes)

0000  88 82 ac 69 56 ec                                 ...iV.

No.     Time        Source                Destination           Protocol Length Info
     69 13.875393   192.168.1.5           192.168.1.17          TCP      60     4510 > 31025 [ACK] Seq=268 Ack=293 Win=15680 Len=0

Frame 69: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x76f2 (30450)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x4077 [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 268, Ack: 293, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     70 13.875425   192.168.1.17          192.168.1.5           TCP      56     31025 > 4510 [PSH, ACK] Seq=293 Ack=268 Win=65432 Len=2

Frame 70: 56 bytes on wire (448 bits), 56 bytes captured (448 bits)
Ethernet II, Src: AsustekC_43:86:1b (00:1d:60:43:86:1b), Dst: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0)
Internet Protocol Version 4, Src: 192.168.1.17 (192.168.1.17), Dst: 192.168.1.5 (192.168.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 42
    Identification: 0x36fc (14076)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x406b (maybe caused by "IP checksum offload"?)]
    Source: 192.168.1.17 (192.168.1.17)
    Destination: 192.168.1.5 (192.168.1.5)
Transmission Control Protocol, Src Port: 31025 (31025), Dst Port: 4510 (4510), Seq: 293, Ack: 268, Len: 2
Data (2 bytes)

0000  af 81                                             ..

No.     Time        Source                Destination           Protocol Length Info
     71 13.876797   192.168.1.5           192.168.1.17          TCP      60     4510 > 31025 [ACK] Seq=268 Ack=295 Win=15680 Len=0

Frame 71: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x76f3 (30451)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x4076 [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 268, Ack: 295, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    153 18.818747   192.168.1.5           192.168.1.17          TCP      60     4510 > 31025 [FIN, ACK] Seq=268 Ack=295 Win=15680 Len=0

Frame 153: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x76f4 (30452)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x4075 [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 268, Ack: 295, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    154 18.818791   192.168.1.17          192.168.1.5           TCP      54     31025 > 4510 [ACK] Seq=295 Ack=269 Win=65432 Len=0

Frame 154: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: AsustekC_43:86:1b (00:1d:60:43:86:1b), Dst: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0)
Internet Protocol Version 4, Src: 192.168.1.17 (192.168.1.17), Dst: 192.168.1.5 (192.168.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x3724 (14116)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x4045 (maybe caused by "IP checksum offload"?)]
    Source: 192.168.1.17 (192.168.1.17)
    Destination: 192.168.1.5 (192.168.1.5)
Transmission Control Protocol, Src Port: 31025 (31025), Dst Port: 4510 (4510), Seq: 295, Ack: 269, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    155 18.819259   192.168.1.17          192.168.1.5           TCP      54     31025 > 4510 [FIN, ACK] Seq=295 Ack=269 Win=65432 Len=0

Frame 155: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: AsustekC_43:86:1b (00:1d:60:43:86:1b), Dst: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0)
Internet Protocol Version 4, Src: 192.168.1.17 (192.168.1.17), Dst: 192.168.1.5 (192.168.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x3725 (14117)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x4044 (maybe caused by "IP checksum offload"?)]
    Source: 192.168.1.17 (192.168.1.17)
    Destination: 192.168.1.5 (192.168.1.5)
Transmission Control Protocol, Src Port: 31025 (31025), Dst Port: 4510 (4510), Seq: 295, Ack: 269, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    156 18.820503   192.168.1.5           192.168.1.17          TCP      60     4510 > 31025 [ACK] Seq=269 Ack=296 Win=15680 Len=0

Frame 156: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: IntelCor_b0:ed:a0 (00:24:d7:b0:ed:a0), Dst: AsustekC_43:86:1b (00:1d:60:43:86:1b)
Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.17 (192.168.1.17)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 40
    Identification: 0x76f5 (30453)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x4074 [correct]
    Source: 192.168.1.5 (192.168.1.5)
    Destination: 192.168.1.17 (192.168.1.17)
Transmission Control Protocol, Src Port: 4510 (4510), Dst Port: 31025 (31025), Seq: 269, Ack: 296, Len: 0

Mar 8, 2012 at 3:50 AM

Fyi, that is simply;

Client connects.

Client sends message

Server sends a message

Server initiates close

Coordinator
Mar 8, 2012 at 3:51 AM

I also don't know.

I have done a fix, please get that latest source code!

Mar 9, 2012 at 12:37 AM
Edited Mar 9, 2012 at 12:38 AM

Still takes 5 seconds before force connect :)

 

Edit: I can't be sure it is websocket4net or websocket-node acting improperly :)

Coordinator
Mar 9, 2012 at 12:42 AM

Could  you try .NET websocket client (Not a Silverlight one) to test against the server?

At the same time, please add the configuration node below in your client's app.config:

 

 

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.Net.Sockets" maxdatasize="1024">
        <listeners>
          <add name="SocketTrace"/>
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add name="SocketTrace"
           type="System.Diagnostics.TextWriterTraceListener"
           initializeData="System.Net.Trace.log" />
    </sharedListeners>
    <switches>
      <add name="System.Net.Sockets" value="Verbose" />
    </switches>
  </system.diagnostics>

 

 

After you produce the issue, please share the Trace log file with me.

Mar 9, 2012 at 1:51 AM
Edited Mar 9, 2012 at 1:52 AM

Hi Kerry,

Here is the log after following your instructions.  My expectation is that the connection should close near 9:46:56, but it took until 9:47:01 (my assumption being that the server forced close after failed close handshake)

 

 

System.Net.Sockets Verbose: 0 : [8068] Socket#13062350::Socket(InterNetwork#2)
System.Net.Sockets Verbose: 0 : [8068] Exiting Socket#13062350::Socket() 
System.Net.Sockets Verbose: 0 : [8068] Socket#13062350::ConnectAsync()
System.Net.Sockets Verbose: 0 : [8068] Socket#13062350::InternalBind(0:0#0)
System.Net.Sockets Verbose: 0 : [8068] Exiting Socket#13062350::InternalBind() 
System.Net.Sockets Verbose: 0 : [8068] Exiting Socket#13062350::ConnectAsync() 	-> True#1
System.Net.Sockets Information: 0 : [13884] Socket#13062350 - Created connection from 192.168.174.1:48812 to 192.168.174.134:4510.
System.Net.Sockets Verbose: 0 : [13884] Socket#13062350::SendAsync()
System.Net.Sockets Verbose: 0 : [13884] Socket#13062350::SendAsync(True#1)
System.Net.Sockets Verbose: 0 : [2056] Data from Socket#13062350::FinishOperation(SendAsync)
System.Net.Sockets Verbose: 0 : [13884] Socket#13062350::ReceiveAsync()
System.Net.Sockets Verbose: 0 : [2056] 00000000 : 47 45 54 20 2F 20 48 54-54 50 2F 31 2E 31 0D 0A : GET / HTTP/1.1..
System.Net.Sockets Verbose: 0 : [2056] 00000010 : 55 70 67 72 61 64 65 3A-20 57 65 62 53 6F 63 6B : Upgrade: WebSock
System.Net.Sockets Verbose: 0 : [2056] 00000020 : 65 74 0D 0A 43 6F 6E 6E-65 63 74 69 6F 6E 3A 20 : et..Connection: 
System.Net.Sockets Verbose: 0 : [2056] 00000030 : 55 70 67 72 61 64 65 0D-0A 53 65 63 2D 57 65 62 : Upgrade..Sec-Web
System.Net.Sockets Verbose: 0 : [2056] 00000040 : 53 6F 63 6B 65 74 2D 56-65 72 73 69 6F 6E 3A 20 : Socket-Version: 
System.Net.Sockets Verbose: 0 : [13884] Exiting Socket#13062350::ReceiveAsync() 	-> True#1
System.Net.Sockets Verbose: 0 : [6516] Data from Socket#13062350::FinishOperation(ReceiveAsync)
System.Net.Sockets Verbose: 0 : [6516] 00000000 : 48 54 54 50 2F 31 2E 31-20 31 30 31 20 53 77 69 : HTTP/1.1 101 Swi
System.Net.Sockets Verbose: 0 : [6516] 00000010 : 74 63 68 69 6E 67 20 50-72 6F 74 6F 63 6F 6C 73 : tching Protocols
System.Net.Sockets Verbose: 0 : [2056] 00000050 : 31 33 0D 0A 53 65 63 2D-57 65 62 53 6F 63 6B 65 : 13..Sec-WebSocke
System.Net.Sockets Verbose: 0 : [2056] 00000060 : 74 2D 4B 65 79 3A 20 59-54 4A 6B 4D 47 45 7A 4E : t-Key: YTJkMGEzN
System.Net.Sockets Verbose: 0 : [2056] 00000070 : 7A 67 74 5A 6D 4E 69 4F-43 30 30 5A 51 3D 3D 0D : zgtZmNiOC00ZQ==.
System.Net.Sockets Verbose: 0 : [6516] 00000020 : 0D 0A 55 70 67 72 61 64-65 3A 20 77 65 62 73 6F : ..Upgrade: webso
System.Net.Sockets Verbose: 0 : [2056] 00000080 : 0A 48 6F 73 74 3A 20 31-39 32 2E 31 36 38 2E 31 : .Host: 192.168.1
System.Net.Sockets Verbose: 0 : [6516] 00000030 : 63 6B 65 74 0D 0A 43 6F-6E 6E 65 63 74 69 6F 6E : cket..Connection
System.Net.Sockets Verbose: 0 : [6516] 00000040 : 3A 20 55 70 67 72 61 64-65 0D 0A 53 65 63 2D 57 : : Upgrade..Sec-W
System.Net.Sockets Verbose: 0 : [2056] 00000090 : 37 34 2E 31 33 34 3A 34-35 31 30 0D 0A 4F 72 69 : 74.134:4510..Ori
System.Net.Sockets Verbose: 0 : [2056] 000000A0 : 67 69 6E 3A 20 31 39 32-2E 31 36 38 2E 31 37 34 : gin: 192.168.174
System.Net.Sockets Verbose: 0 : [2056] 000000B0 : 2E 31 33 34 0D 0A 53 65-63 2D 57 65 62 53 6F 63 : .134..Sec-WebSoc
System.Net.Sockets Verbose: 0 : [2056] 000000C0 : 6B 65 74 2D 50 72 6F 74-6F 63 6F 6C 3A 20 65 6E : ket-Protocol: en
System.Net.Sockets Verbose: 0 : [2056] 000000D0 : 66 75 73 65 70 72 6F 74-6F 63 6F 6C 0D 0A 0D 0A : fuseprotocol....
System.Net.Sockets Verbose: 0 : [6516] 00000050 : 65 62 53 6F 63 6B 65 74-2D 41 63 63 65 70 74 3A : ebSocket-Accept:
System.Net.Sockets Verbose: 0 : [6516] 00000060 : 20 42 67 4E 50 55 77 76-66 61 46 77 6E 35 73 46 :  BgNPUwvfaFwn5sF
System.Net.Sockets Verbose: 0 : [6516] 00000070 : 35 79 56 37 4E 59 33 50-76 74 62 30 3D 0D 0A 53 : 5yV7NY3Pvtb0=..S
System.Net.Sockets Verbose: 0 : [6516] 00000080 : 65 63 2D 57 65 62 53 6F-63 6B 65 74 2D 50 72 6F : ec-WebSocket-Pro
System.Net.Sockets Verbose: 0 : [6516] 00000090 : 74 6F 63 6F 6C 3A 20 65-6E 66 75 73 65 70 72 6F : tocol: enfusepro
System.Net.Sockets Verbose: 0 : [6516] 000000A0 : 74 6F 63 6F 6C 0D 0A 4F-72 69 67 69 6E 3A 20 31 : tocol..Origin: 1
System.Net.Sockets Verbose: 0 : [6516] 000000B0 : 39 32 2E 31 36 38 2E 31-37 34 2E 31 33 34 0D 0A : 92.168.174.134..
System.Net.Sockets Verbose: 0 : [6516] 000000C0 : 0D 0A                                           : ..
Connected 3/8/2012 9:46:56 PM
System.Net.Sockets Verbose: 0 : [6516] Socket#13062350::SendAsync()
System.Net.Sockets Verbose: 0 : [6516] Socket#13062350::SendAsync(True#1)
System.Net.Sockets Verbose: 0 : [7768] Data from Socket#13062350::FinishOperation(SendAsync)
System.Net.Sockets Verbose: 0 : [6516] Socket#13062350::ReceiveAsync()
System.Net.Sockets Verbose: 0 : [7768] 00000000 : 81 E4 92 AE AC 4A                               : .....J
System.Net.Sockets Verbose: 0 : [7768] Socket#13062350::SendAsync()
System.Net.Sockets Verbose: 0 : [7768] Socket#13062350::SendAsync(True#1)
System.Net.Sockets Verbose: 0 : [6516] Exiting Socket#13062350::ReceiveAsync() 	-> True#1
System.Net.Sockets Verbose: 0 : [2056] Data from Socket#13062350::FinishOperation(ReceiveAsync)
System.Net.Sockets Verbose: 0 : [2056] 00000000 : 81 47 53 75 62 73 63 72-69 70 74 69 6F 6E 20 46 : .GSubscription F
System.Net.Sockets Verbose: 0 : [2056] 00000010 : 61 69 6C 65 64 20 2D 20-67 61 74 65 77 61 79 20 : ailed - gateway 
System.Net.Sockets Verbose: 0 : [2056] 00000020 : 69 73 20 6E 6F 74 20 63-6F 6E 6E 65 63 74 65 64 : is not connected
System.Net.Sockets Verbose: 0 : [2056] 00000030 : 20 74 6F 20 74 68 65 20-72 65 61 6C 74 69 6D 65 :  to the realtime
System.Net.Sockets Verbose: 0 : [13884] Data from Socket#13062350::FinishOperation(SendAsync)
System.Net.Sockets Verbose: 0 : [2056] 00000040 : 20 73 65 72 76 69 63 65-2E                      :  service.
System.Net.Sockets Verbose: 0 : [13884] 00000000 : E9 8C CF 25 FC DA DE 25-FE C2 C9 38 B0 8E 96 6A : ...%...%...8...j
System.Net.Sockets Verbose: 0 : [13884] 00000010 : B0 FC C9 2B FE DA C5 27-F7 8C 80 6A B0 CF CF 3E : ...+...'...j...>
System.Net.Sockets Verbose: 0 : [13884] 00000020 : FB C1 C2 68 B2 94 8C 68-C1 DB CE 39 F1 DC C5 28 : ...h...h...9...(
System.Net.Sockets Verbose: 0 : [13884] 00000030 : F7 8C 80 6A B0 CA CD 3E-F3 8C 8C 70 B2 D5 8E 2D : ...j...>...p...-
System.Net.Sockets Verbose: 0 : [13884] 00000040 : F3 DA C9 3D F3 D7 E5 2E-B0 8E 96 6A B0 9F 9C 7A : ...=.......j...z
System.Net.Sockets Verbose: 0 : [13884] 00000050 : B0 82 8C 68 F1 DE D9 03-F6 8C 8C 70 B2 8C 9E 7A : ...h.......p...z
System.Net.Sockets Verbose: 0 : [13884] 00000060 : A2 8C D1 37                                     : ...7
Subscription Failed - gateway is not connected to the realtime service.
System.Net.Sockets Verbose: 0 : [2056] Socket#13062350::ReceiveAsync()
System.Net.Sockets Verbose: 0 : [2056] Exiting Socket#13062350::ReceiveAsync() 	-> True#1
System.Net.Sockets Verbose: 0 : [13884] Data from Socket#13062350::FinishOperation(ReceiveAsync)
System.Net.Sockets Verbose: 0 : [13884] 00000000 : 88 02 03 E8                                     : ....
System.Net.Sockets Verbose: 0 : [13884] Socket#13062350::SendAsync()
System.Net.Sockets Verbose: 0 : [13884] Socket#13062350::SendAsync(True#1)
System.Net.Sockets Verbose: 0 : [6516] Data from Socket#13062350::FinishOperation(SendAsync)
System.Net.Sockets Verbose: 0 : [13884] Socket#13062350::ReceiveAsync()
System.Net.Sockets Verbose: 0 : [13884] Exiting Socket#13062350::ReceiveAsync() 	-> True#1
System.Net.Sockets Verbose: 0 : [6516] 00000000 : 88 84 15 49 CA 85                               : ...I..
System.Net.Sockets Verbose: 0 : [6516] Socket#13062350::SendAsync()
System.Net.Sockets Verbose: 0 : [6516] Socket#13062350::SendAsync(True#1)
System.Net.Sockets Verbose: 0 : [8436] Data from Socket#13062350::FinishOperation(SendAsync)
System.Net.Sockets Verbose: 0 : [8436] 00000000 : 16 A1 CA 85                                     : ....
System.Net.Sockets Verbose: 0 : [8436] Socket#13062350::Shutdown(Both#2)
System.Net.Sockets Verbose: 0 : [8436] Exiting Socket#13062350::Shutdown() 
System.Net.Sockets Verbose: 0 : [8436] Socket#13062350::Close()
System.Net.Sockets Verbose: 0 : [8436] Socket#13062350::Dispose()
System.Net.Sockets Verbose: 0 : [8436] Exiting Socket#13062350::Close() 
Connection closed.3/8/2012 9:47:01 PM
Coordinator
Mar 9, 2012 at 2:33 AM

It is very helpfull. Something strange show front of me.
The server side sent two closing handshakes, but there might be some unexpected things happened.

Coordinator
Mar 9, 2012 at 2:37 AM

Could you debug into the code WebSocketCommandInfo.cs to see what happened for the code below:

if (frame.OpCode == OpCode.Close)
            {
                if (length >= 2)
                {
                    var closeStatusCode = frame.InnerData.ToArrayData(offset, 2);
                    CloseStatusCode = closeStatusCode[0] * 256 + closeStatusCode[1];

                    if (length > 2)
                    {
                        Text = frame.InnerData.Decode(Encoding.UTF8, offset + 2, length - 2);
                    }
                    else
                    {
                        Text = string.Empty;
                    }

                    return;
                }
            }

Coordinator
Mar 9, 2012 at 2:48 AM

Oh, I found the bug. It's really a bug of WebSocket4Net, I am very sorry for that, for wasting so much time of you.

I'll fix it ASAP.

Coordinator
Mar 9, 2012 at 2:48 AM

Oh, I found the bug. It's really a bug of WebSocket4Net, I am very sorry for that, for wasting so much time of you.

I'll fix it ASAP.

Coordinator
Mar 9, 2012 at 3:57 AM

I did a fix for it, could you checkout the latest source code?

Mar 10, 2012 at 11:39 PM

Hi Kerry,

No problem at all :)

Still seeing the behavior after latest version.  Log is below.  Server begins close handshake at 7:35:51, and forcefully closes at 7:35:56 after handshake fails (is my assumption)

System.Net.Sockets Verbose: 0 : [11932] Socket#15409429::Socket(InterNetwork#2)
System.Net.Sockets Verbose: 0 : [11932] Exiting Socket#15409429::Socket() 
System.Net.Sockets Verbose: 0 : [11932] Socket#15409429::ConnectAsync()
System.Net.Sockets Verbose: 0 : [11932] Socket#15409429::InternalBind(0:0#0)
System.Net.Sockets Verbose: 0 : [11932] Exiting Socket#15409429::InternalBind() 
System.Net.Sockets Verbose: 0 : [11932] Exiting Socket#15409429::ConnectAsync() 	-> True#1
System.Net.Sockets Information: 0 : [5240] Socket#15409429 - Created connection from 192.168.174.1:63142 to 192.168.174.139:4510.
System.Net.Sockets Verbose: 0 : [5240] Socket#15409429::SendAsync()
System.Net.Sockets Verbose: 0 : [5240] Socket#15409429::SendAsync(True#1)
System.Net.Sockets Verbose: 0 : [3648] Data from Socket#15409429::FinishOperation(SendAsync)
System.Net.Sockets Verbose: 0 : [5240] Socket#15409429::ReceiveAsync()
System.Net.Sockets Verbose: 0 : [3648] 00000000 : 47 45 54 20 2F 20 48 54-54 50 2F 31 2E 31 0D 0A : GET / HTTP/1.1..
System.Net.Sockets Verbose: 0 : [10404] Data from Socket#15409429::FinishOperation(ReceiveAsync)
System.Net.Sockets Verbose: 0 : [10404] 00000000 : 48 54 54 50 2F 31 2E 31-20 31 30 31 20 53 77 69 : HTTP/1.1 101 Swi
System.Net.Sockets Verbose: 0 : [10404] 00000010 : 74 63 68 69 6E 67 20 50-72 6F 74 6F 63 6F 6C 73 : tching Protocols
System.Net.Sockets Verbose: 0 : [10404] 00000020 : 0D 0A 55 70 67 72 61 64-65 3A 20 77 65 62 73 6F : ..Upgrade: webso
System.Net.Sockets Verbose: 0 : [3648] 00000010 : 55 70 67 72 61 64 65 3A-20 57 65 62 53 6F 63 6B : Upgrade: WebSock
System.Net.Sockets Verbose: 0 : [3648] 00000020 : 65 74 0D 0A 43 6F 6E 6E-65 63 74 69 6F 6E 3A 20 : et..Connection: 
System.Net.Sockets Verbose: 0 : [5240] Exiting Socket#15409429::ReceiveAsync() 	-> True#1
System.Net.Sockets Verbose: 0 : [3648] 00000030 : 55 70 67 72 61 64 65 0D-0A 53 65 63 2D 57 65 62 : Upgrade..Sec-Web
System.Net.Sockets Verbose: 0 : [3648] 00000040 : 53 6F 63 6B 65 74 2D 56-65 72 73 69 6F 6E 3A 20 : Socket-Version: 
System.Net.Sockets Verbose: 0 : [3648] 00000050 : 31 33 0D 0A 53 65 63 2D-57 65 62 53 6F 63 6B 65 : 13..Sec-WebSocke
System.Net.Sockets Verbose: 0 : [3648] 00000060 : 74 2D 4B 65 79 3A 20 4D-6A 49 30 4E 32 51 30 4D : t-Key: MjI0N2Q0M
System.Net.Sockets Verbose: 0 : [3648] 00000070 : 57 45 74 59 6A 67 7A 59-79 30 30 5A 41 3D 3D 0D : WEtYjgzYy00ZA==.
System.Net.Sockets Verbose: 0 : [10404] 00000030 : 63 6B 65 74 0D 0A 43 6F-6E 6E 65 63 74 69 6F 6E : cket..Connection
System.Net.Sockets Verbose: 0 : [10404] 00000040 : 3A 20 55 70 67 72 61 64-65 0D 0A 53 65 63 2D 57 : : Upgrade..Sec-W
System.Net.Sockets Verbose: 0 : [10404] 00000050 : 65 62 53 6F 63 6B 65 74-2D 41 63 63 65 70 74 3A : ebSocket-Accept:
System.Net.Sockets Verbose: 0 : [10404] 00000060 : 20 37 31 46 38 59 48 4C-69 59 31 36 55 6B 33 4E :  71F8YHLiY16Uk3N
System.Net.Sockets Verbose: 0 : [10404] 00000070 : 4A 68 68 64 79 70 34 76-37 5A 68 59 3D 0D 0A 53 : Jhhdyp4v7ZhY=..S
System.Net.Sockets Verbose: 0 : [10404] 00000080 : 65 63 2D 57 65 62 53 6F-63 6B 65 74 2D 50 72 6F : ec-WebSocket-Pro
System.Net.Sockets Verbose: 0 : [10404] 00000090 : 74 6F 63 6F 6C 3A 20 65-6E 66 75 73 65 70 72 6F : tocol: enfusepro
System.Net.Sockets Verbose: 0 : [3648] 00000080 : 0A 48 6F 73 74 3A 20 31-39 32 2E 31 36 38 2E 31 : .Host: 192.168.1
System.Net.Sockets Verbose: 0 : [3648] 00000090 : 37 34 2E 31 33 39 3A 34-35 31 30 0D 0A 4F 72 69 : 74.139:4510..Ori
System.Net.Sockets Verbose: 0 : [3648] 000000A0 : 67 69 6E 3A 20 31 39 32-2E 31 36 38 2E 31 37 34 : gin: 192.168.174
System.Net.Sockets Verbose: 0 : [3648] 000000B0 : 2E 31 33 39 0D 0A 53 65-63 2D 57 65 62 53 6F 63 : .139..Sec-WebSoc
System.Net.Sockets Verbose: 0 : [3648] 000000C0 : 6B 65 74 2D 50 72 6F 74-6F 63 6F 6C 3A 20 65 6E : ket-Protocol: en
System.Net.Sockets Verbose: 0 : [3648] 000000D0 : 66 75 73 65 70 72 6F 74-6F 63 6F 6C 0D 0A 0D 0A : fuseprotocol....
System.Net.Sockets Verbose: 0 : [10404] 000000A0 : 74 6F 63 6F 6C 0D 0A 4F-72 69 67 69 6E 3A 20 31 : tocol..Origin: 1
System.Net.Sockets Verbose: 0 : [10404] 000000B0 : 39 32 2E 31 36 38 2E 31-37 34 2E 31 33 39 0D 0A : 92.168.174.139..
System.Net.Sockets Verbose: 0 : [10404] 000000C0 : 0D 0A                                           : ..
Connected 3/10/2012 7:35:51 PM
System.Net.Sockets Verbose: 0 : [10404] Socket#15409429::SendAsync()
System.Net.Sockets Verbose: 0 : [10404] Socket#15409429::SendAsync(True#1)
System.Net.Sockets Verbose: 0 : [5240] Data from Socket#15409429::FinishOperation(SendAsync)
System.Net.Sockets Verbose: 0 : [10404] Socket#15409429::ReceiveAsync()
System.Net.Sockets Verbose: 0 : [10404] Exiting Socket#15409429::ReceiveAsync() 	-> True#1
System.Net.Sockets Verbose: 0 : [5240] 00000000 : 81 E4 E1 11 56 D1                               : ....V.
System.Net.Sockets Verbose: 0 : [5240] Socket#15409429::SendAsync()
System.Net.Sockets Verbose: 0 : [5240] Socket#15409429::SendAsync(True#1)
System.Net.Sockets Verbose: 0 : [10404] Data from Socket#15409429::FinishOperation(ReceiveAsync)
System.Net.Sockets Verbose: 0 : [10404] 00000000 : 81 47 53 75 62 73 63 72-69 70 74 69 6F 6E 20 46 : .GSubscription F
System.Net.Sockets Verbose: 0 : [10404] 00000010 : 61 69 6C 65 64 20 2D 20-67 61 74 65 77 61 79 20 : ailed - gateway 
System.Net.Sockets Verbose: 0 : [10404] 00000020 : 69 73 20 6E 6F 74 20 63-6F 6E 6E 65 63 74 65 64 : is not connected
System.Net.Sockets Verbose: 0 : [10404] 00000030 : 20 74 6F 20 74 68 65 20-72 65 61 6C 74 69 6D 65 :  to the realtime
System.Net.Sockets Verbose: 0 : [10404] 00000040 : 20 73 65 72 76 69 63 65-2E                      :  service.
System.Net.Sockets Verbose: 0 : [11428] Data from Socket#15409429::FinishOperation(SendAsync)
System.Net.Sockets Verbose: 0 : [11428] 00000000 : 9A 33 35 BE 8F 65 24 BE-8D 7D 33 A3 C3 31 6C F1 : .35..e$..}3..1l.
System.Net.Sockets Verbose: 0 : [11428] 00000010 : C3 43 33 B0 8D 65 3F BC-84 33 7A F1 C3 70 35 A5 : .C3..e?..3z..p5.
System.Net.Sockets Verbose: 0 : [11428] 00000020 : 88 7E 38 F3 C1 2B 76 F3-B2 64 34 A2 82 63 3F B3 : .~8..+v..d4..c?.
System.Net.Sockets Verbose: 0 : [11428] 00000030 : 84 33 7A F1 C3 75 37 A5-80 33 76 EB C1 6A 74 B6 : .3z..u7..3v..jt.
System.Net.Sockets Verbose: 0 : [11428] 00000040 : 80 65 33 A6 80 68 1F B5-C3 31 6C F1 C3 20 66 E1 : .e3..h...1l.. f.
System.Net.Sockets Verbose: 0 : [11428] 00000050 : C3 3D 76 F3 82 61 23 98-85 33 76 EB C1 33 64 E1 : .=v..a#..3v..3d.
System.Net.Sockets Verbose: 0 : [11428] 00000060 : D1 33 2B AC                                     : .3+.
3/10/2012 7:35:51 PM Subscription Failed - gateway is not connected to the realtime service.
System.Net.Sockets Verbose: 0 : [10404] Socket#15409429::ReceiveAsync()
System.Net.Sockets Verbose: 0 : [10404] Exiting Socket#15409429::ReceiveAsync() 	-> True#1
System.Net.Sockets Verbose: 0 : [5240] Data from Socket#15409429::FinishOperation(ReceiveAsync)
System.Net.Sockets Verbose: 0 : [5240] 00000000 : 88 02 03 E8                                     : ....
System.Net.Sockets Verbose: 0 : [5240] Socket#15409429::SendAsync()
System.Net.Sockets Verbose: 0 : [5240] Socket#15409429::SendAsync(True#1)
System.Net.Sockets Verbose: 0 : [5240] Socket#15409429::ReceiveAsync()
System.Net.Sockets Verbose: 0 : [5240] Exiting Socket#15409429::ReceiveAsync() 	-> True#1
System.Net.Sockets Verbose: 0 : [3648] Data from Socket#15409429::FinishOperation(SendAsync)
System.Net.Sockets Verbose: 0 : [3648] 00000000 : 88 82 65 13 8D BE                               : ..e...
System.Net.Sockets Verbose: 0 : [3648] Socket#15409429::SendAsync()
System.Net.Sockets Verbose: 0 : [3648] Socket#15409429::SendAsync(True#1)
System.Net.Sockets Verbose: 0 : [5240] Data from Socket#15409429::FinishOperation(SendAsync)
System.Net.Sockets Verbose: 0 : [5240] 00000000 : 66 FB                                           : f.


<< 5 second gap here>>



System.Net.Sockets Verbose: 0 : [10404] Socket#15409429::Shutdown(Both#2) System.Net.Sockets Verbose: 0 : [10404] Exiting Socket#15409429::Shutdown() System.Net.Sockets Verbose: 0 : [10404] Socket#15409429::Close() System.Net.Sockets Verbose: 0 : [10404] Socket#15409429::Dispose() System.Net.Sockets Verbose: 0 : [10404] Exiting Socket#15409429::Close()
3/10/2012 7:35:56 PM Connection closed.

Coordinator
Mar 11, 2012 at 3:12 PM

According the log, WebSocket4Net had sent the correct closing handshake.

Dec 11, 2012 at 11:50 PM

I'm seeing the same issue itzlegend mentioned in his original post.  I get "An attempt was made to access a socket in a way forbidden by its access permissions."  I've created a clientaccesspolicy.xml file and placed in on my web root (http://mysystemname).  The socket address is on the same system (ws://mysystemname/socket).  I've placed my Silverlight xap and html page in the web root.  I'm setting ClientAccessPolicyProtocol to Http.  I can see in Fiddler that clientaccesspolicy.xml is accessed, but I still get this error.  What should the clientaccesspolicy.xml files content be to allow this to work from Silverlight?  I assume that's the problem.

Bonus question...  Is there a way if the html page is loaded using file protocol for websocket access to work?

Jan 19, 2013 at 6:38 AM

I'm having the same problem as joedomoto....   Any resolution?  I've changed my clientaccesspolicy.xml a dozen times.  It's being downloaded but not having any effect. 

Same project runs fine in out of browser mode with full permissions.


Jan 29, 2013 at 4:49 PM

hi,
I am having the same problen with SL5 browser client. The clientaccesspolicy.xml is accessed and the application is working in OOB mode. The same code with c# winforms is working fine and the server is accessible with JS, too. Only the Silverlight app in browser does not work. (I have inserted the port into clientaccesspolicy file: <socket-resource port="8089" protocol="tcp" />) 
Has anyone found any solution?
Thanks,
sosenk 

 

Jan 29, 2013 at 8:33 PM

I have not...   After spending entirely too much time creating different clientaccesspolicy.xml files and stepping through the websocket code trying to figure out what's going on I just resorted to  using different code for in browser vs. OOB.    Which is messy, but works.

In my case I'm just using port 80 with a .net version of socket IO so it's easy enough to resort to the JavaScript version of socket IO when running in browser.

I don't know if internally there is something preventing "supersocket" from connecting to this port when running in browser versus OOB, but I could never get it to work.

Jun 17, 2014 at 6:38 PM
Same issue with SL5 browser client. The clientaccesspolicy.xml is accessed and the application is working from Visual Studio. Can someone guide as to what the clientaccesspolicy.xml should look like?
WebSocket websocket = new WebSocket("ws://" + _ArcGISGeoEventServer + ":" + _ArcGISGeoEventServerPort + "/ws-" + serviceName);

            websocket.ClientAccessPolicyProtocol = System.Net.Sockets.SocketClientAccessPolicyProtocol.Http;
<policy>
      <allow-from>
        <domain uri="file:///" />
      </allow-from>
      <grant-to>
        <socket-resource port="6100-6200" protocol="tcp" />
      </grant-to>
    </policy>
Thanks

Neeraj