I'm reading http and here is my problem, how and why TCP RST packet from the server ( connection reset by peer ) can leades to erase all the input buffer of client? why it is so serious?
and also is there any way to keep that information?
also another question comes in my mind, this can be happend by server anytime it wants? I mean we can use it to kind of attack to a client? use it for our benefit??
tnx in advance
I know maybe these questions would sounds stupid but i tried and i cann't find any convenient answer.
Related
The description of the questions goes like this:
Someone recorded all the IP packets of a TCP connection between a client and a server for 30 minutes. In the record, he didn't find any packet that was ACK-only. How is this possible?
What is claimed to be a possible solution: For all the record time, the server sent data to the client, which the client processed, but he didn't send any data back to the server.
I am having trouble understanding how can it be possible.
From what I see, since the client didn't send any data to the server, and there weren't any ACK-only packets in the record, then the server didn't get any ACK from the client. Logically, I would think that since no ACK is received by the server, it will always do re-transmit. But also, since the server doesn't get anything from the client for 30 minutes, which seems like a long time for me, it will conclude that the connection is broken and stop it. (maybe even send an ACK only, but I am not sure about it).
Moreover, from what I know, when using keepalive, the sender gets and ACK-only packet from his peer.
Can anyone help me understand this?
Help would be appreciated
Perhaps more details would be helpful here. What kind of server/client? What protocol is being used and for what purpose?
Is the connection running as expected and this is just viewed as strange traffic you are trying to understand or is the connection timing out?
Some devices or softwares can be set to a "No ACK" state which means that no ACKs are sent nor are they expected.
One reason for this is usually bandwidth. ACKs do consume bandwidth and there are cases where bandwidth is such a great premium that packets being lost is preferable to bandwidth being consumed by ACKs. That type of traffic would probably do better with a UDP protocol but that is a completely different topic.
Another reason is that you don't care if packets are lost. Again, this would be better off as UDP instead of TCP, but someone may be trying to work within strange parameters is bending the rules about what type of traffic to advertise as in order to get around some issue.
Hopefully this is helpful, but if it does not apply, then please put in more details about the connection so that we can better understand what may be happening.
as stated above, im trying to checking connection between server and client, without using ping, or some packet that will send every second.
i already try ping method, but this method will cause flooding, and i already try tcp method that act like icmp, the tcp packet will send tcp packet every second, to make sure the connection betweet sever and client still on, but this doesnt solve the flooding problem.
do you guys have any idea how to do this, without causing flooding?
all i need is server only send like 3 way handshake, and the connection built, and when the client off, something will trigger the server, and tell that server that, this client in particular are offline.
in simple, how to monitor client and server connectoin without sending multiple packet?
thank you
Say some link halfway between the client and server stops passing traffic. It may or may not still be possible for the client and server to communicate, depending on whether there are alternate links. But there is no way to tell whether or not that communication is possible without doing something active. There is no passive way to tell whether or not a link failure has made a connection usable or unusable.
There is, in general, no easier or more efficient way to tell whether or not communication is possible than attempting that communication and seeing whether or not it works.
I have a server for a very competitive game which involves money. In order for the game to be fair, every client must have the same ping. I can't, obviously, make everyone have a short ping. So the only solution is to fix it high: for example, 200ms is acceptable.
The problem is, how do I force a ping to be 200ms? In order for that to work, I'd have to know how much I should delay sending the packets - and, for that, I'd have to know the ping of the client. So, if the ping is 60ms, I could just add a 140ms delay to provided data. The problem is: I can only know the ping by asking it, and a client can lie, telling me his ping is higher than it is and making me send the packets earlier.
How to solve that problem?
you can't fix the ping, it can change all the time. if your client enable e.g. torrent during your ping discovery it will significantly affects the result.
but maybe you don't have to delay sending packets. maybe it's enough to delay receiving or analyzing them? and that might be easier, you just have to know when you sent the corresponding packet
there is also other option: many online shooters use feature called 'unlagged'. client sends the coordinate of his shoot and server, based on current ping (lets say 80ms) calculate if the target would have been hit 80ms ago. if so, the target is considered hit. but this of course introduces some artifacts like the victim getting the shot through the wall.
By 'ping' I assume you mean 'network latency', which is variable and entirely outside your control. Your question doesn't make sense.
I hope i will explain my question correctly.
I would like to make a request, to a url or a entity that lives at some port or address
and whatever is listening at that port will take the request and run with it, but will not
respond at all and neither will the client wait for the response, it will continue doing what needs to be done next,
the server or whatever is listening on that port will do what instructions i layed out in the request and that is it, i do not need confirmation whether what i wanted done got done
is this possible?
if i could sum up my questions it would be how can i make non-blocking to the client http requests to a listener on a remote host
if it is not possible, please explain to me why in short or point me where i could find this info.
Your question embodies a contradiction in terms. HTTP is a request/response protocol.
yeah, when you run -
http.get(myUrl)
with a callback missing, the computer sits around waiting for the response anyway. It's kinda weird, but it's a tenet of HTTP.
you may be interested in UDP, which is more "fire-and-forget", and somewhat similar in the node API. (It's got some gotchas though too!)
I was wondering, is it possible to trace a packet that you send out of your own computer? The idea here would be to build something to protect your data. The packet sent out containing your password and other vital information is open to rerouting by a hacker. I want to know if it is possible (and if so, how I might go about approaching this) to trace the intermediate and/or final destinations of a certain packet, and then have them sent back to my computer for verification.
I would appreciate any help you guys could give on this matter.
There is no mechanism to do what you want. The packet itself might reach its "destination" just fine, only to be further re-directed elsewhere. Consider it like mailing an envelope -- whoever receives it is free to photocopy the contents a thousand times and send the copies to newspapers, tabloids, and telephone poles all over the world.
Same story with data -- once it leaves your computer, you have to trust the remote endpoint to not do anything harmful with it.
TLS and openPGP can go a long way to preventing third-parties from reading or modifying your data while it is in transit, but they cannot make sure the remote peer only handles your data with care.
No, not with ISO OSI, and there are other approaches to protect youre data