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.
Related
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.
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'm writing a simple reverse proxy which will need to handle http GETs and POSTs and WebSocket connections. Numbers of simultaneous clients will be low so I had hoped to use HttpListener. I'm struggling to see how to use that to proxy a WebSocket connection though.
I think responses have to be sent via HttpListenerResponse. For GETs and POSTs this is easy. For WebSockets I'd need to send handshake data then keep the connection open to send further messages from the server being proxyed. The only way I can see to send data using HttpListenerResponse is to call Close(), presumably preventing further use of the underlying socket.
Similar issues presumably exist with trying to use HttpListenerRequest to receive later websocket messages from the client.
Am I missing something here or is there no way to use HttpListener with websockets?
Seems there is no way with HttpListener right now. You have to wait .NET 4.5.
When will I normally need different ports for client-server communication?
(This question is for C# and general socket programming).
I have implemented and been using a simple C# client-server application. Basically:
server listens for client
on accepted/connected
server spawn client thread -
server waits for client to talk
client talk
server respond
client talk
server respond etc.
if client stops talking, then server blocks in NetworkStream.Read() mode forever in that spawned thread unless client-side disconnects.
I am now thinking of the situation where both sides keeps quiet until some event happen on either side then only will the client or server sends data across. As such both needs to be in NetworkStream.Read mode concurrently somehow and also be able to send to each other at the same time (if the event happens on both sides simultaneously).
Do we need different ports in this case or can both client and server be in NetworkStream.BeginRead mode without risking a problem with NetworkStream being in both writing and sending mode at the same time?
Thanks.
Excellent question. I have written more than one app with that architecture. When you need to have bi-directional communication, you need two connections (of course, in two different ports) between client and server:
Connection where requests flow from client to server
Connection where requests flow from server to client
That way, both sides will have a NetworkStream ready to be read. And you notice the level of independence between the two flows, allowing you more control over your bi-directional request handling code.
I do not quite understand how exactly persistent connections work.
So the keepalive property is set by default and this should keep my connection open, as far as I understand it.
So right now I am sending my data via a POST on an HTTPWebRequest.
But I do this everytime I send something to the recipient.
So it is like this:
POST data from client to server, response to the post is returned.
But next i just send another POST, instead of using the connection I already opened. So I feel like I am sending more than I actually have to.
Can't I just open the connection once and then continue communication via this connection?
I am sorry for my poor understanding of this subject, but this is the first time I really work with network protocols.
Thanks in advance
Daniel
KeepAlive was added to HTTP protocol to improve server-side performance.
HTTP is generally a stateless protocol. All state is preserved as cookies or server's session. If KeepAlive is set to true, client and the server could potentially keep their underlying TCP Connection alive.
Usually a time-out set for KeepAlive so that if client did not make any other request, this connection is closed.
This feature is usually implemented differently across different platforms, for example I have seen issues with Java implementation where they do not respect the timeout and server closes the connection so client's attempt to connect again fails since it assumes connection is still open.
See RFC document here.
You can reuse the connection IF the server supports it.... including any proxies in between you and the server. Which is where it sometimes falls down. It was tacked on to HTTP 1.0 and officially added in 1.1.
Basically, your client asks "may I keep this connection alive" with a special header, then if the server supports it, it replies saying "yes" and the client can then send more requests on the same socket.
Your client code also has to support this ability. .Net should be fine.