I am trying to learn more about websocket and its internal implementations. But still can’nt understand few things. I tried googling for a in-depth explanation, but most of them just gives the high-level overview. Following are my doubts
1. According to what I read, web socket server (C# / C++ implementation) by default uses port 80. Although we can use any port, it’s preferred that we use port 80 as we won’t have any firewall issues. If that’s so, how are we supposed to run both the webserver and web socket server on the same port (80)?
2. Let’s assume that the web socket server is running on port 81 and webserver is running on port 80.
So when the browser issues the initial handshake HTTP request (Upgrade: websocket) , this request sent to port 81. Right? If so, this request (See below) does’nt have any relation to an HTTP protocol. But still we use HTTP protocol headers. Why?
GET /mychat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Version: 13
Origin: http://example.com
Why dint they use the same websocket interface currently implemented in most browser to issue a direct TCP/IP connection with the given port, without any HTTP stuff?
3. Is there any packet size limit or data/buffer limit for data sent/received from client/server? If that’s the case, do we need to frame the data and handle it ourselves?
4. Does the websocket server always needs to be a separate service/process? In future will the webserver’s (IIS, apache) will include support for hosting web socket servers within its process space?
By using an HTTP compatible handshake you can integrate a WebSocket handler into your webserver or just have the webserver forward the websocket connection to a dedicated WebSocket server.
The WebSocket handshake uses an HTTP compatible handshake to allow both protocols to be handled easily on the same port and it allows existing firewall configurations to much more easily support WebSocket traffic. In addition, preventing cross-side script attacks in well understood in the context of HTTP requests and so WebSocket leverages that knowledge. Even after the connection is established, WebSocket is not a raw socket connection. It is a message based protocol and therefore requires framing. In addition, the framing is masked when sent from client (browser) to server in order to alleviate fears of a theoretical vulnerability in misbehaving proxies/caches/intermediaries.
There is no limit on message size in the protocol itself. A message can be split into multiple frames. There is a protocol limit to frame size but it's 2^64 bytes. The actual frame size limit will be smaller depending on client/server implementation. If you have multi-megabyte single messages that you want to send you might consider changing your application to use smaller messages to maximize cross-browser and cross-server support.
WebSocket handling can definitely be integrated into web servers and this was very much a scenario envisioned by the working group. For example, consider pywebsocket which is designed to run both standalone or as a mod_python module in Apache. As another example, ASP.NET 4.5 and IIS 8 will have built-in support for WebSockets.
Related
I have a websocket connection where I want to constantly listen and receive events on that websocket's URL. It's a status watcher, and I will be returned a json on a regular basis. I have a signalR client that is listening to a server/hub on one point. There is also a third device, not the signalR server or the battery, that has a websocket connection.
Is it possible to setup a SignalR client, point it to a websocket server that is not signalR, and just listen to all the traffic that way? I have a listener already in the SignalR client built in, could I make a "second hub" and have it listen also to the other websocket on the other device? It's not one I have control over, and is not a SignalR server, but since it's a websocket connection, shouldn't I be able to read off of it?
Here is a high tech diagram to help.
SignalR client cannot connect to any websocket. First, websocket is just one transport that SignalR uses but not the only one. If the client cannot connect to the server it will by default automatically switch to a different transport (e.g. server sent events or long polling). Second, SignalR uses a protocol to talk to the server (if you are interested you can find the protocol description here) - if the protocol is not followed the client won't be able to connect to the server. Hence the SignalR client can only work with a SignalR server.
Recently, we migrated one of our existing web service to WCF service with basic http binding (hosted in IIS). The problem is whenever user sending a long running request (>5min) to the service, the client keep on waiting for server response until closing it manually. After analysing the Wireshark and Firewall logs we found the reason, the default HTTP session timeout set for 300 sec in firewall due to this firewall remove the long running session from the table after 5min.
We can resolve this by increasing HTTP session timeout in firewall but the complexity is we can control it at server side firewall but we can’t control at client side(each client will have different ISP and IT Policy). So my network admin suggested to implement the keep-alive mechanism (sending heart beat message to server) but it doesn’t worked for me.
I tried following things while implementing keep-alive mechanism,
First, I tried to send echo messages to server with the same channel
which created for long running request but it was failed since the
channel already waiting for response.
Then I tried to send echo message to server for every four min with
separate channel but there is not impact on the issue since it using
the brand new connections.
I tried with async service calling pattern but there is no impact.
Finally, I tried by adding the Keep-Alive (Keep-Alive: max=100,
timeout=1801) header for each request and response at both client and
server side again there is no impact on the issue.
So, could you please help me to resolve this issue?
I'm programming an application that listens to ports for specific packets using REGEX. I can see the original TCP Stream, but I'm wondering if this is possible to intercept and stop this stream without any packet forging library.
Example:
A user navigates on a page where there is the word P*RN or "J*st** Bi*ber", and automatically, he loses this specific connection.
If I cannot do it, maybe I'll replace some HTMLElements on the fly.
You can implement a proxy server, so that all traffic from your users to the internet (and back) will go through your proxy. You can implement the proxy using the .NET networking API (no packet forging). When you want to drop the connection, you can either close the TCP stream, or send back an error response.
This solution has some problems too:
you have to implement specific proxy for each protocol you want to filter (SMTP, IMAP, POP3)
you need to force your users to use your proxy server when connecting to internet (this could be configured at network level)
it will not work with SSL (HTTPS), since the traffic is encrypted
Edit
I don't think there is a way how to intercept TCP streams using .NET API. However you can forward TCP streams (accepting client connection and then forwarding all communication between the client and the server). Since you accepted the client TCP connection, you can also terminate it.
I have created a WCF server in a PC named PC1. I access the URI http://PC1:8000/ServiceModelSamples/Service using internet explorer from another PC named PC2.
When I debug the messages in Wireshark, I am confused that why there is no HTTP message, even though I specify "http://" in my URI. It only shows TCP protocol, there is no HTTP message or header.
Please advice
To wireshark, any browser request is just another TCP connection. As far as showing the HTTP protocol details is concerned, it might be guessing that traffic on a specific port (80) would be http. Since you are using a non-standard http port, it might not be able to do so.
To confirm this, try loading some other website/webpage (e.g. www.google.com) and see if it is able to show you http details. If it works, then next thing would be try and find some setting/configuration by which you can tell wireshark that it should treat traffic from another port (8000 in your case) as http traffic.
EDIT:
See this question as a guide to configure wireshark for http ports.
HTTP is an application layer protocol that sits on top of TCP, the transport layer protocol.
See http://en.wikipedia.org/wiki/TCP/IP_model for more information.
When you access the service using a browser, a "friendly" service responds to generate a web form to your browser. If you get a web page back in your browser, it is HTTP. That's not part of the "SOAP" spec, but it is part of the MS WCF stack supporting HTTP.
Then, if you fill it out, you might be POSTing or GETing the form, but POST is the default. That's also HTTP. GET is often disabled in WCF.
Then, you get back XMLish stuff in your browser, that also came by HTTP.
So you might just be missing an HTTP protocol decode in wireshark.
EDIT: I didn't see your URL included :8000. Wireshark won't decode that as HTTP unless you force it to, because it's not on the HTTP port. You can right-click on a port 8000 packet and say "follow conversation", and you'll see all the http goodness. You can also force wireshark to decode that stream as HTTP, which will let you "drill into" the packets past the TCP layer.
We have a custom chat application(c#) which uses TCPClient. We are having problem on clients who are behind Firewall or proxy. We know that these client can browse the internet without a problem so we decided to change our TCPClient application so that It uses HTTP messages to communicate.
Will it be enough just to wrap our text massages with standard HTML tags and HTTP headers? We need a long lasting connection. Does keep-alive have a limit? Do firewalls or proxies have time limits for "alive" connections.
You would need to change your protocol, probably pretty significantly. There's no guarantee that a proxy is going to use the same TCP connection for subsequent HTTP requests, it has the freedom to close any connection after receiving a message from the server, and they generally will after only a few idle seconds.
Unless your protocol can work stateless, then it isn't going to work over HTTP through a proxy.