I have a client - server app that uses NSStream to connect. sometimes when trying to open a connection, one side of the connection gets NSStreamEventEndEncountered when first trying to send a message.
I use the bridge between CFStream and NSStream. My server create a socket with:
_ipv4cfsock = CFSocketCreate(kCFAllocatorDefault,PF_INET, SOCK_STREAM,IPPROTO_TCP, kCFSocketAcceptCallBack, handleConnect, &info);
In the handleConnect callback function, CFStreamCreatePairWithSocketis used to get two CFStream.
My client use CFStreamCreatePairWithSocketToHost to connect to the host.
The client connects (Creates NSStreams) and then sends a ping. When my server receives a connection it opens a NSStream, and when it recieve a ping it sends a pong.
When one of the connection closes the other should get a NSStreanEventEndEncountered as I have set kCFStreamPropertyShouldCloseNativeSocket to true on the streams.
I get several different results: I used NSLog to see what was happening.
-Most of the time the connection opens and works as expected.
Server did recieve new connection
Server recieved ping
Server Sent pong
Client recieved pong
-The connection closes (NSStreamEventEndEncountered) when trying to send the pong. The client doesn't recieve the pong but recieve NSStreamEventEndEncountered
Server did recieve new connection
Server recieved ping
Server recieved pong
Server closed
Client closed
-The connection closes (NSStreamEventEndEncountered) when trying to send the ping. The server doesn't recieve the ping or NSStreamEventEndEncountered
Server did recieve new connection
Client closed
-An error is recieved when trying to send the ping:
Server did recieve new connection;
Error recieved: The operation couldn’t be completed. Connection reset by peer
Both the client and the server are on my computer. Why does the stream get a NSStreamEventEndEncountered when trying to write?
I found the issue, I had a buffer that was sent as soon as my connection opened. If no data was in this buffer, an empty buffer was sent, which is an end signal for the streams.
From Apple Doc:
If the other end of the connection closes the connection:
Your connection delegate’s stream:handleEvent: method is called with
streamEvent set to NSStreamEventHasBytesAvailable. When you read from
that stream, you get a length of zero (0).
Your connection delegate’s stream:handleEvent: method is called with streamEvent set to
NSStreamEventEndEncountered.
When either of these two events occurs,
the delegate method is responsible for detecting the end-of-file
condition and cleaning up.
Related
I am working on a product which uses ZeroMQ (version 4.0.1).
The server and client communicate based on ZeroMQ ROUTER-socket.
To read socket events, server and client also create socket-monitor sockets (PAIR). There are three ports on which server binds and listens. Out of these three ports, one port is in a non-secured mode. Other two ports are using md5-authentication.
The issue I am facing is that, both the server and the client spontaneously receive socket disconnect for one of the secure port sockets (please see a log below). I have checked multiple times that server and client both have L3 reachability to each other.
What else I should check for?
What really triggers this error scenario?
zmq_print_callback:ZmQ: int zmq::stream_engine_t::read(void*, size_t):923
Stream engine recv():
TCP socket (187) to unknown:0 was disconnected
with error 107 [Transport endpoint is not connected]
Below sequence of events can trigger this error on server
Server receives ACCEPTED event for clientY and gets FD1.
Link-flap/network issue happens and clientY disconnects but server does not receive this disconnect.
Network recovers and clientY connects back to server.
Server receives ACCEPTED event for clientY and gets FD2. However, packets sent to this sockets does not go out of the server.
After 1 min or so, clientY receives "Transport endpoint is not connected error" for FD1.
Application can use this to treat as client disconnect.
I have a system with server/client applications. The client will send in socket connection request and the server will accept the socket connection when it's working correctly. However, in some situations (most likely due to ungraceful socket disconnection like system shutdown on client side or crash), the client will not be able to reconnect to the server application. The Wireshark capture shows the client will continue to try to connect; but after going through SYN->SYN,ACK->ACK, the server application will send RST. At this point, sometimes the netstat -an will show the connection is in CLOSE_WAIT state and other times would not show this connection. The capture shows 'Acknowledgment Number: Broken TCP. The ackowledge field is nonzero while the ACK flag is not set.
My questions is why the server application would send this RST?
Who can show me the reason error TortoiseSVN, when I connect SVN-Repo to update resource
The error detail:
I has already checked the
SVN server is running
Ping to IP server ok
I attached message error:
Error: Unable to connect to a repository at URL 'https://........'
Error running context: A request to send or receive data was
disallowed because the socket is not connected and (when sending on a
datagram socket using a sendto call) no address was supplied.
Hope Everyone help me show the way to fix it.
I have already found the problem, my server svn disabled svn-ports
Error running context: A request to send or receive data was
disallowed because the socket is not connected and (when sending on a
datagram socket using a sendto call) no address was supplied.
I'm writing an application that attempts to do the following:
create a TCP server listening on an available port
create a TCP socket that connects to the server
have the server socket write data to the client
have the server socket close its end of the connection
have the client write a message to the server
Here's where the problem lies. When I attempt to run the application, the TCP exchange goes like this:
The first three packets establish the three-way handshake, and the fourth and fifth packets are the transmission of the data written by the server and its acknowledgement.
As expected, the server socket sends a packet with the FIN flag set to indicate that it is closing its end of the connection. The client acknowledges this and then attempts to write its data to the socket. The server immediately sends an RST packet, terminating the connection prematurely.
Why does this happen?
Note: the above capture was done on Windows 8.1.
The sender cannot send data after a [FIN]. Such an action will result in the receiver issuing an [RST].
The FIN probably indicates that the server has fully closed the connection in both directions. In this case if it receives any further data on the connection it will issue an RST. This suggests an application protocol error on your part. If the server sends a reply and then closes the socket, the client can't send anything else via that connection.
Possibly you need your server to call shutdown() with SHUT_WR and then read something else from the client before closing the socket. Or possibly you're just doing it wrong.
I have a client-server (Java) application using persistent TCP connections, but sometimes the Server receives java.io.IOException: Connection reset by peer exception when trying to write on the socket, however I don't see any error in the Client log.
This RST is probably caused by an intermediate proxy/router, but if that's the case, should this be seen on the client as well?
If the RST is sent by the client, it can be seen on it using a packet sniffer such as wireshark. However, it won't show up in any user-level sockets since it's sent by the OS as a response to various erroneous inputs (such as connection attempts to a closed port).
If the RST is sent by the network, then it's pretending to be the client to sever the connection. It can do so in one direction, or in both of them. In that case, the client might not see anything, except for a RST sent by the actual server when the client continues to send data to a connection it perceives as open, while the server sees it as closed.
Try capturing the traffic on both the server and the client, see where the resets are coming from.