Does TCP have something in place for telling a client "continue this same conversation but at a different address"?
There is no way to do that with TCP. You would have to make the client close its current connection and open a new connection. Or else you would need a proxy that can manage multiple connections on its side and switch between them as needed, then have the client connect to the proxy.
Related
help me please. I'm new and have little experience. There is a task, a permanent TCP connection to the LDAP server. There are several options. Nginx, HAProxy, ssh multiplexing. I settled on HAProxyn. But I can't figure out if it can observe a TCP-enabled connection. This is necessary so that each new request does not open a new connection to the server, and use the existing one. Can you suggest what I can use for this?
On each new request - HAProxy open new connection. But I need that all requests go through one TCP connections
My understanding regarding network model communication:
Application layer:
1. HTTP(Not Persistent or stateless): For exchanging messages like get, post, put etc. Here connection is made to webserver and disconnected after sending response. So server will not keep track of the previous requests.
2. Websockets(Persistent or statefull): For creating a communication channel that will be open to exchange data. Here we can keep track of the previous requests. Like we can know how many users are currently connected to our server.
Transport layer:
TCP(Persistant and Statefull): Will let the server know to which application to connect using port number. Both HTTP and web sockets will work upon this layer.
Considering working with HTTP and TCP:
I make a HTTP request from browser(application layer):
Connects to web server sends all files requested and also makes a TCP connection with the application(transport layer).
After sending response it's disconnected.
My confusion:
I got totally confused when I heard, read that TCP is Statefull and Persistant connection.
Q1. Now after step three is browser still connected to webserver because of TCP?
Q2. Is the context object we get in server side in c# code is the complete request packet with HTTP info, TCP info, function to invoke or controller to invoke in MVC etc?
Q3. If client and server are still connected with TCP. Then on next HTTP request does it will use the available TCP connection or will create new TCP and HTTP connection? Why can't it use previous TCP to communicate? Or TCP will be destroyed after HTTP? Or what's happening?
As the title suggests, should Ping Frames only be sent from a server or it is better to have both endpoints send them? As mentioned in the Websocket RFC:
NOTE: A Ping frame may serve either as a keepalive...
So by by having one endpoint sending a ping request it should keep the connection open, right?
The second part of above line is this:
or as a means to verify that the remote endpoint is still responsive.
I'm new to the concept of websockets but if the connection closes from the server won't the client be notified?
Consider the case where the server just goes away, maybe it crashes. Who or what will notify the client of this? Or say a network link close to the server is down for so long that by the time it comes back up, the server has totally forgotten about this client. Who or what would tell the client?
There are three possibilities:
The client does not need to detect loss of the connection. In this case, there's nothing special you need to do.
The client has some way to detect loss of the connection already. For example, if the connection is idle for some period of time, the client could send an application-level query and timeout if it gets no response or if the query fails.
The client needs to detect loss of the connection but has no existing way to do this. In this case, using pings makes sense.
In a typical query/response protocol, the client usually doesn't need to ping the server because there's some query it can send that has the same effect. Unless the protocol layered above websocket supports some way for the server to query the client, the server often has only two choices: use pings to detect lost connections or disconnect idle clients.
Both variants has ways of implementation. For example in case if server sends ping to client, then client can get information that server disconnected by have a loop with deadline timer which is reset every time when ping is received. If the timer reaches dealine, then it's mean that server disconnected.
I want to know few basic things about connection establishment between client and server.
suppose my web page has left menu where i have some links, on click of those child pages
are open in the right side of master page .Now each link is requesting a new web page to
the server. Each web page is calling 5-6 web services asynchronously to get the data. So
if i am clicking on a left menu link, a connection is established between client and
server using (client IP and Port) to (server Ip and port). But before the response comes,
suppose i clicked on other link of menu then how server knows that old conneciton is
terminated and new connection is established.next thing,when i clicked on a link, request
goes to server, server process the request but before sending the response if connection
is terminated from client side, what happens to that response, does server discards the
response and takes the new request for process.
actually i have lot of confusion, so if anyone can explain me the full client-server round trip process,that will really very helpful .
Thanks in advance
Server will discard the response and will work in subsequent requests. Reading about Hypertext Transfer Protocol will make you understand more. You can search on internet one of article is here
The request and response is made over TCP which is connection oriented protocol as the connection breaks IIS will know that client if not accessible. You try http://www.google.com.pk:80 will take you to http://www.google.com.pk as we can omit default port i.e. 80. Try this http://www.google.com.pk:82/ it will not open www.google.com as tcp connection could not be made on port 82.
At the moment I have an existing application which basically consists of a desktop GUI and a TCP server. The client connects to the server, and the server notifies the client if something interesting happens.
Now I'm supposed to replace the desktop GUI by a web GUI, and I'm wondering if I have to rewrite the server to send http packets instead of tcp packets or if I can somehow use some sort of proxy to grab the tcp packets and forward them to the web client?
Do I need some sort of comet server?
If you can make your client ask something like "Whats new pal?" to your server from time to time you can start implementing HTTP server emulator over TCP - its fun and easy process. And you could have any web based GUI.
You can just add to your TCP responds Http headers - itll probably do=)
So I mean HTTP is just a TCP with some headers like shown in here.
You should probably install fiddler and monitor some http requests/ responses you normally do on the web and you'll get how to turn your TCP server into http emulator=)
If you want keep sockets based approche use flash (there is some socket api) or silverlight (there is socket API and you can go for NetTcpBinding or Duplexbinding something like that - it would provide you with ability to receive messages from server when server wants you to receive them (server pushes messages))
So probably you should tall us which back end you plan to use so we could recomend to you something more usefull.