RE: [dsdp-tcf-dev] Re: TCF agent issue

["Tarassov, Eugene" <eugene.tarassov@xxxxxxxxxxxxx>]

Hi Karun,

TCP/IP has timeout like mechanism that can detect the board has been
powered off: TCP "keepalive". Currently it is turned off in the agent.
Since you gave a good reason to turn it on, I will commit a fix for
that.

Thanks,
Eugene.

-----Original Message-----
From: Karun SARASWAT [mailto:karun.saraswat@xxxxxx] 
Sent: Wednesday, April 29, 2009 10:15 PM
To: Tarassov, Eugene; 'DSDP TCF dev list'
Subject: RE: [dsdp-tcf-dev] Re: TCF agent issue

Hi Eugene,

I am running TCF agent on a ARM board which I poweroff while client is
still waiting for response. Client never detects the board has been
powered off.

I think, the case you mentioned holds good if the agent was shutdown or
killed by kernel resulting in socket shutdown ( I tested this by issuing
reboot on target). But if agent is powered off without these steps,
client cannot detect the remote peer shutdown. I am not very well versed
with TCP/IP so cannot differentiate why the behaviour is different in
two cases.
This is just a guess.

I think TCF should have some timeout like mechanism where if the agent
is not discovered ( No UDP_ACK_INFO ) for some time, it cancels current
as well as all pending requests and try to reconnect to agent again. May
be reconnection step can be left for application layer only, leaving the
client to original connected state waiting for connection to be made
again.

Best Regards,
Karun

 

-----Original Message-----
From: Tarassov, Eugene [mailto:eugene.tarassov@xxxxxxxxxxxxx]
Sent: Wednesday, April 29, 2009 21:23
To: DSDP TCF dev list; Karun Saraswat
Subject: RE: [dsdp-tcf-dev] Re: TCF agent issue

Hi Karun,

If the agent dies (or connection is broken for any other reason), the
framework closes the channel, aborts pending commands and notifies the
client through ReplyHandlerCB callback passing ERR_CHANNEL_CLOSED error
code, see protocol.c line 495.

The client can handle the error code by re-opening channel and
re-sending the command. However, if the command changes remote state,
re-sending the command might be not the best thing to do.

Regards,
Eugene.

-----Original Message-----
From: dsdp-tcf-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Martin Oberhuber
Sent: Wednesday, April 29, 2009 7:26 AM
To: Karun Saraswat; dsdp-tcf-dev@xxxxxxxxxxx
Subject: [dsdp-tcf-dev] Re: TCF agent issue

Hello Karun,

this is a good question. Since we expect an agent to never die, I'd
rephrase the question a little:

What happens if the connection to an agent is broken during
communications, e.g. due to plugging out a network cable? Are there any
timeouts / exceptions? Is there any retry logic inside the TCF layer, or
would clients of TCF need to implement that on their application layer?

Any ideas or suggestions for code, anyone?

Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River Target
Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm




Karun Saraswat wrote:
> Hi all,
> 
> I have one small issue regarding C based TCF. Can anybody please help?
> 
> How client will handle the case if agent die without replying to 
> command issued and wait endlessly for reply from agent? Does current 
> framework support this scenerio, when same agent powers up again? Can 
> I resume and abondon the last command? Also can somebody provide me 
> some pointer how this can be done? I am exploring the code so it will 
> help me to arrive to a solution quickly.
> 
> Thanks
> Karun
> 
> 
_______________________________________________
dsdp-tcf-dev mailing list
dsdp-tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tcf-dev