Hi
I'm using AT91sam7x512 with DP83848 for Ethernet connection and in my project device is set as host, and every thing is OK except TCP closed detection.
I've used tcp_get_state() to determine which state my device is. but it's really unreliable and maybe after 10 minute I could detect that the connection was lost and sometimes never I could.
my cable connected to the PC through Ethernet switch and I've set timeout to 120.
in configuration of DP83848 I've used auto negotiation mode to connect and there's not any difference between auto neg. and fixed mode(100BT or something else)
Does anybody have suggestion?
if you could help, I'd appreciate you.
thanks
Are you talking about a correct TCP closure or a disconnection of a cable?
If you're talking about TCP closure, then the stack provides an event to tell you of it.
If you're talking about trying to detect when the cable has been disconnected (or cut), then the TCP protocol stack will not directly tell you of the event.
For example when an application connect to this device as a client if I try to close the connection in PC or close that application, my device doesn't show me anything. in the other worlds running and closing application in PC for two times will cause such problem.
these are the same in unplugging the cable or closing the connection by software.
anyway when the client be disconnected, the server's port is open and never be closed for a long while or forever.
No, it is not the same thing to close a TCP connection and to disconnect a network cable.
You just can't see a disconnected cable without trying to send data and notice the transfer failure.
So a TCP connection with KEEP_ALIVE will notice a disconnected cable, but a connection without may think it is connected days later.
One side actually closing a connection on the other hand means that the two TCP/IP stacks will talk with each other and make sure that both sides knows that the connection is getting closed.
If you connect using telnet to another computer somewhere, and the connection is unreliable, you can see that if you use KEEP_CONNECT, and go to bed, the connection will probably have disconnected in the morning. If you didn't use KEEP_CONNECT, it really doesn't matter if there is a link between the two machines until you try to press a key and your side notices that it fails to communicate.
I swear that there is no any difference between unplugging and closing port by software in my device. both of them take me a long time to detect.
I couldn't get you about KEEP_ALIVE, what is it?
I've used RL-ARM and I have just tcp_get_state to recognize the TCP status.
here per each received data packet in my device, I try to send a packet to client side, so there is no way to send a packet to detect TCP closure without any received packet.
would you please tell me more about this matter?
if here is an optimized and standard way to detect such a thing maybe I'd change my implementation policy.
thanks in advance
I swear that there is no any difference between unplugging and closing port by software in my device
NNNNNNNNNNNNNNNOOOOOOOOOOOOOOOOOOOOOOO
1. Listen to what you are told 2. Read about TCP/IP design philosophy and you will understand. 3. No near to swear here.
"I've used RL-ARM and I have just tcp_get_state to recognize the TCP status."
Hopefully, you've implemented a callback function as per the RL-ARM documentation - The one whose address is passed to the function tcp_get_socket.
Within that, you check for the event TCP_EVT_CLOSE to detect when the socket has been properly terminated.
For you, the KEEP_ALIVE might be worth reading about. Typically, this is a TCP packet that is sent periodically and automatically by the TCP stack. The other side of the session would be expected to send an acknowledgement for the packet - So if no acknowledgement is received (within a reasonable timeframe), the connection is terminated. The frequency of the KEEP_ALIVE is reasonably long (typically something like 1-10 minutes) and the timeout mighty be of a similar time - So the detection of a missing cable should not be expected to be immediate.
I said my device behavior is in this way(they are the same just because of time to detect). I know there is difference between unplug and colsing port by software.
and I've used all you said (callback and other else)
How can I check TCP stack?
thank you
"and I've used all you said (callback and other else)"
So do you get the event to tell you of the TCP session closure?
"How can I check TCP stack?"
For what? The callback tells you when the closure is detected.
Oh my GOD, please help me
I said I've used all routines same as callback, and with this situation I have such a problem.
I don't know could you get me what I said: I've written callback routine and when I closed the port connection after a long while the condition of TCP_EVT_CLOSE will be true and the microcontroller could detect the closure of connection(and sometimes never), same as below which is on uVision help:
#include <rtl.h> U8 tcp_soc; U16 tcp_callback (U8 soc, U8 event, U8 *ptr, U16 par) { /* This function is called on TCP event */ .. switch (event) { case TCP_EVT_CONREQ: /* Remote host is trying to connect to our TCP socket. */ /* 'ptr' points to Remote IP, 'par' holds the remote port. */ .. /* Return 1 to accept connection, or 0 to reject connection */ return (1); case TCP_EVT_ABORT: /* Connection was aborted */ .. break; case TCP_EVT_CONNECT: /* Socket is connected to remote peer. */ .. break; case TCP_EVT_CLOSE: /* Connection has been closed */ .. break; case TCP_EVT_ACK: /* Our sent data has been acknowledged by remote peer */ .. break; case TCP_EVT_DATA: /* TCP data frame has been received, 'ptr' points to data */ /* Data length is 'par' bytes */ .. break; } return (0); } void main (void) { init (); /* Initialize the TcpNet */ init_TcpNet (); tcp_soc = tcp_get_socket (TCP_TYPE_SERVER, 0, 30, tcp_callback); if (tcp_soc != 0) { /* Start listening on TCP port 80 */ tcp_listen (tcp_soc, 80); } while (1); /* Run main TcpNet 'thread' */ main_TcpNet (); .. } }
after closure there is no any event to recognition or it's too late.
So have you gone back to the basics and tried one of the Keil demo programs?
What result do you get from that?
View all questions in Keil forum