It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I recently am attempting to study the TCP, but a post graduate tell me the FIN is also used in going to create a connection, that 3 handshakes.
Following is my mind to the process of 3 handshakes:
Client A post a datagram within SYN to Client B.
Client B received it, and immediately posted another datagram within SYN and ACK.
Client A received it, and immediately posted another datagram within ACK to Client B.
When the 3rd step is DONE, the connection is going to be built.
Here is the question, I don't find any datagram with FIN in 3 steps.
FIN is not used in creating a connection. It's used to close a connection.
However, the connection can be closed with FIN halfway through a handshake, as this diagram makes clear. Perhaps this is what the Post Grad was referring to?
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
As expected behavior, when server sends FIN-ACK packet, client should also send FIN-ACK packet and the connection is terminated. But for some of my cases, when server sends FIN-ACK packet, immediately new http request is going from the client, before FIN-ACK is sent back from client. This is causing connection reset packet. What is the reason behind this and how to solve this issue.
... when server sends FIN-ACK packet, client should also send FIN-ACK packet ...
While common this is not actually required. FIN from a server signals only that the server will not send any more data - but it still might receive data. Similar a FIN from the client signals that the client will not send any more data - but it might also still receive data. Only when both sides have send a FIN and got the matching ACK, then it is clear that no more data will be send in both direction and thus the connection is closed.
... when server sends FIN-ACK packet, immediately new request is going from the client, before FIN-ACK is sent back from client.
There is no "request" at the TCP level. Request and response have only a meaning at the application level for some application protocols. It is unclear what application protocol is spoken here.
What is the reason behind this and how to solve this issue.
As said above, FIN from the server only means that the server will not send any more data. But it might still receive data. Nothing here forbids the client to send more data. There is no issue to solve here.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
TCP can detect whether a packet was sent successfully anyways so instead of waiting for the pong, why not just check if there's an error when the ping is sent? I just don't find the need for pong.
Having ping and pong creates an end-to-end test for both connectivity and a functional endpoint at the other end.
Using just TCP, only confirms that the TCP stack says the packet was delivered to the next stop in a potential connectivity chain and does not confirm that the other endpoint is actually functioning (only that the packet was delivered to the TCP stack).
This is particularly important when there are proxies or other intermediaries in the networking chain between endpoints which is very often the case in professionally hosted environments. Only a ping and pong confirms that the entire end-to-end chain, including both client and server are fully functioning.
Here's a related answer: WebSockets ping/pong, why not TCP keepalive?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
So anywhere I read anything about UDP, people say this;
Messages can be received out of order
It's possible a message never arrives at all
The first one isn't clear to me. This is what can happen with TCP:
I send 1234, client receives 12 and then 34
So no problem; just prepend the message length and it's all good. After all, an integer is always 4 bytes, so even if the client receives the prepended length in 2 goes, it will know to keep reading until it has at least 4 bytes to know the msg length.
Anyway, back to UDP, what's the deal now when people say 'packages can be received out of order'?
A) Send `1234`, client receives `34` and then `12`
B) Send `1234` and `5678`, client receives `5678` and then `1234`
If it's A, I don't see how I can make UDP work for me at all. How would the client ever know what's what?
It's entirely possible that a network has many paths to reach a given point, so one of the datagram could take one route to reach the other end, another packet could take another path. Given this, the last packet sent could arrive before another packet. UDP takes no measures to correct this, as there's no notion of a connection, and in-order delivery.
At this points it depends on how you send your data. For UDP, each send() or similar call sends one UDP datagram, and recv() receives one datagram. A datagrams can be reordered with respect to other datagrams, or disappear entirely. Data cannot be reordered or dropped within a datagram, you either receive exactly the message that was sent, or you don't receive it at all.
If you need datagrams/messages to arrive in order, you need to add a sequence number to your packets, queue and reorder them at the receiving end.
The usual metaphore is:
TCP is a telephone conversation: words arrive in the same order as they were spoken
UDP is sending a series of letters by mail: the letters may get lost, may arrive, and can arrive in any order.
TCP also involves a connection : if the telephone line is disrupted by a thunderstorm, the connection breaks, and has to be built up again. (you need to dial again)
UDP is connectionless and unreliable: if the mailman is hit by a truck, some letters may be lost. Some letters could also be picked up and delivered by other mailmen. Letters can even be dropped on the floor if your mailbox is full, and even without any reason.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
According Google the following are the facts on usage of ports:
The Well Known Ports are those from 0 through 1023. The Registered
Ports are those from 1024 through 49151 The Dynamic and/or Private
Ports are those from 49152 through 65535
How can i connect more than 65535 users to a single server. because we need to provide a socket to every new listening connection? so wont it create a new port locally for every connection?
A single connection is defined by pair IPserver:server_port and IPclient:client_port. Given that you server_port is just one and is fixed, and your client is defined by IPclient:client_port, it gives a theoretical range of 2^48(32 of IPv4 + 16 of PORT) different clients, so you can have 2^48 parallel connections to a single server.
The limit is that you can't set more than 2^16 connections from a single IP to a single server.
All incoming connections to a listening port use that port. So your problem does not exist, unless you mean you want more than 65535 connections all from the same client host, which would be a strange requirement.
One IP address can only hold a 2 bytes port, as is defined in TCP and UDP protocol. One possible workaround can be like this:
server fork n processes, echo listening on 192.168.0.(10+i):9999.(i = 0 to n-1)
clients try to connect 192.168.0.10:9999, if fail(192.168.0.10 has no more ports available thus connection cannot be established), then try 192.168.0.11:9999 and so on.
As to how to bind multiple IPs to a single NIC, check this: http://community.spiceworks.com/how_to/show/1782-bind-multiple-ips-to-one-nic-in-linux
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
When we use SSL(Secured Socket Level) Server has private key whereas client has public key.
In such cases client encrypt data and server decrypt it to get actual details, but how it will work if server is sending some critical financial details to client. In this situation as client has only public key so whether it is possible for key to decrypt details.
In short how secure communication from server-->Client works.
Public key cryptography is only used during the SSL/TLS handshake to agree on shared keys. The encryption/decryption of the data on top of SSL/TLS is then done using these shared keys.
You should read about Diffie-Hellman Key Exchange and RSA Key Exchange.
Here is a document describing the principles of the key exchange: http://technet.microsoft.com/en-us/library/cc962035.aspx
There is also a description of how this applies to SSL/TLS here: http://technet.microsoft.com/en-us/library/cc783349%28WS.10%29.aspx#w2k3tr_schan_how_eicp
Well, in reverse? The server logs in to the client with ssl in the same way as the client would log into the server? That is, if you require a separate connection. If the server sends back the sensitive information within the same secure session, there is no security problem.
But maybe I don't understand your question correctly :)
I think that after server sends his key to client, client can generate a private key and send it over SSL to the server. After that both client and server can use their private key to comunticate. I'm not an expert but that make sense