Hi
I've used At91sam7x512 and keil sample codes for TCP connection but here is a kind of problem when I try to disconnect my board in my tcp_callback routine I'll get TCP_EVT_CLOSE condition and here I called tcp_close(soc)
when I use tcp_get_state before tcp_close the result is 10 (TCP_STATE_CONNECT) and after that it's 255 (!!!)
and if I wait for 2 or more minutes my tcp_callback have been called again but with TCP_EVT_ABORT condition.
during this time gap, I'm in listening mode but nobody can connect to my device.
below code is a part of my work and I used printf to get state of tcp in different positions:
case TCP_EVT_CLOSE: printf("1:%d\r\n",tcp_get_state(soc)); tcp_close(soc); tcp_release_cocket(soc); printf("2:%d\r\n",tcp_get_state(soc)); initializetcp(); . . . case TCP_EVT_ABORT: printf("3:%d\r\n",tcp_get_state(soc)); tcp_abort(soc); tcp_release_cocket(soc); printf("4:%d\r\n",tcp_get_state(soc)); initializetcp(); . . .
and in initializetcp routine I try to get socket and listen. and I've used tcp_abort instead of tcp_close in TCP_EVT_CLOSE condition but they were the same and the problem was exist
and I've got such a result from hyperteminal:
1:10 2:255
(after 2 minute)
3:8 4:255
although when I try to close my program in PC there is no any problem but when my application program throw an exception such problem will occur.
what's going wrong here?
thanks in advance
you're right IB Shy but if I myself have implemented the client side. for example I can send "hello client" and if in client side get such a packet I'd ignore it.
but if I try to send packet with data included AScomm.net give me an exception.
(I want to send packet without data to check the reaction of ASComm.net ... but, doesn't matter)
anyway
thank guys for your responses
your posts were very useful for me
thanks thanks thanks
"TCP RFC said as a keepalive packet you can send a packet with no any data or with garbage data"
That's not quite how I remember it being described!?
Data is data is data. How can you send garbage data? How would any TCP stack know that an application is sending garbage data as opposed to non-garbage data?
TCPnet is definitely NOT unusual in NOT providing a facility to issue keepalive packets at will from within an application.
Why should any MODBUS organisation help you? Your problem isn't with any error in any standard.
Create dummy reads then. Ask the client once/second even if you only need data once/minute or whatever.
I know what you mean. but, indeed my project works based on MODBUS TCP and here is a function to process raw data and makes MODBUS packet for transmission and for receiving data, process MODBUS packet to main data and commands.
TCP RFC said as a keepalive packet you can send a packet with no any data or with garbage data
RL-ARM can't send a packet with no data and if I try to send data as a keepalive packet the MODBUS program on the other side (client side) couldn't pass it and throw an exception. I'm using free license of ASComm.net and has such a problem.
I know here is not website of MODBUS but I've used OPEN MODBUS and because of that MODBUS organization doesn't help me.
this project is about my dissertation.
if anybody knows how could I implement keepalive with these limitations, I'd appreciate him.
thanks.
"Note that checking the state of the PHY only helps with a cable being disconnected locally."
A very valid point.
I'd also add that if you really need to check for broken connections quickly then TCP/IP over Ethernet is not always the most suitable anyway. Like many other communication mediums, Ethernet is, by definition, non-deterministic. Errors can (and quite often do) occur, which cause retransmissions and therefore delays.
Note that checking the state of the PHY only helps with a cable being disconnected locally. It doesn't tell what happens on the other side of the first switch, and there may be a huge number of network routers between your unit and the other end.
KeepAlive - or regular own messages - will catch even these errors. But since regular transfers represents a form of polling, the polling frequency decides how fast you will notice a problem.
Note also that in many situations, TCP/IP will be able to retransmit and keep the connection alive even if a user shortly disconnects/reconnects a wire or reboots a router. Having too hard requirements - for example by looking for ping times - may be counterproductive.
"Do you agree with keepalive method ,or not?"
It really does depend on the requirements. For a connection that is expected to stay alive for a long time with long gaps in the communication, it can be useful. If data is being sent/received with gaps shorter than the keepalive rate then there is little point in having the keepalives. If you want the connection to tidily close when inactive, then keepalives would need to be disabled anyway.
"How can I send a TCP packet with zero lenght of data?"
As far as I am aware, you cannot send a TCP packet of zero length using TCPnet, but that should not be a requirement ...
Technically, when you send data from an application over TCP it is in a stream and the fact that the data is sent in packets should not be important.
thanks IB Shy
I tried to read PHY status register ... but it gave me zero as a result ... but something here was dropped out and that was setting PHY to MDI enable... I've forgot it and now with such a routine works properly:
unsigned short int status; MDI_Enable(); status=Read_PHY(0x10); if ((status & 1)) printf("lan is connected\r\n"); else printf("lan has been disconnected\r\n"); MDI_Disable();
here, I could recognize LAN link status very fast.
and about keepalive: Do you agree with keepalive method ,or not? because I've read RFC for TCP and keepalive in this document was not a good method.
I need to know the connection is still alive or not.
with these methods which you said (reading the PHY status and moving the port closing routine to main process), connection is reliable enough but I want to prevent any unexpected problems.
How can I send a TCP packet with zero lenght of data?
thank thank thank
"...but is there any solution in RL-ARM? or not?"
None of which I'm aware.
You may want to look at keepalives.
You may want to look at sending periodic packets as part of your communication protocols.
Neither of these will tell you of:
1) a cable disconnection very soon after it occurs 2) brief intermittent communication problems
In my opinion, the best way is to interrogate the PHY.
I don't know why but I tried it and always give me zero as a result and it's nonsense.
but thanks I'll try it more and more... but is there any solution in RL-ARM? or not?
thanks a lot
"when the cable be unplugged link indicator of PHY (DP83848) will show me that the cable was unplugged very fast but there is no any act on software till timeout occur."
Most (if not all) PHYs have the ability to check the link state - You can poll the status and determine whether the cable connection is good. Check the PHY documentation for details.
Hi all
you said:
I would suggest you move all but the most basic code out of the callback into the main TCP processing task
I tried to move get socket routine to another place (to main task) and connection will close as well
thanks a lot IB Shy
but here is another problem with my board
when the cable be unplugged link indicator of PHY (DP83848) will show me that the cable was unplugged very fast but there is no any act on software till timeout occur.
how can I aware such an event very fast?
although I found somethings about keepalive routine but I can not send zero length packet. (tcp_send give me an error)
is keepalive essential for TCP connection? if yes how?
Yes,
I would strongly second the moving of code out of the call_back routine, generate events here to signal your main tcp_routine.
regards Darren
In your Net_config.c, under the entry, 'Number of TCP Sockets' what did you set your value for? this is the Max # of sockets you can have at a time.
Are you trying to open more sockets in your project that the maximum number than you specified? That would cause an error to occur.
I think this might be more related to a TCPnet limitation where you must be VERY careful what you call from within a TCP callback. Especially the part where you say:
"...in initializetcp routine I try to get socket and listen."
from within your TCP_EVT_CLOSE condition.
The details concerning the ability to do is were (and possibly still are still) very sketchy.
When I first encountered it, the support team unfortunately were unable to provide me with further details and simply said that their documentation needed updating!
I would suggest you move all but the most basic code out of the callback into the main TCP processing task.
View all questions in Keil forum