[En-Nut-Discussion] NutTcpAccept() timeout

[Michael Smola]

Hi all,

I did a private hack once to NutTcpConnect to get a non-blocking version.
It followed exactly the fourth approach of Brett, adding a timeout parameter
to NutTcpConnect.
Easy job, good results.

Its obvious, that changing the existing function would lead to nasty
incompatibilities with
existing applications. Although I would not have a problem changing the
existing function, it
would be nicer to add new functionality with a new function name (e.g. the
proposed NutTcpTryAccept).
Adding an "obsolete" comment to the existing functions documentation may
allow a smoother migration.

I don't like approach 2. because I always have a bad feeling doing things in
global variables.

I hate approach 1., all is said in Brett's comments!

Long talk, short vote: approach 3: "adding of new API's, marking of
NutTcpConnect as obsolete".

...have fun...

	Michi


-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de]On Behalf Of Brett Abbott
Sent: Thursday, July 20, 2006 21:34
To: Ethernut User Chat (English)
Subject: Re: [En-Nut-Discussion] NutTcpAccept() timeout


Hi

Im torn 4 ways.

1. Existing option name to affect behaviour.  This will save adding
additional space in the Socket but will cause unpredicted results for
the existing code because someone will forget to change their source or
miss it.    Better to stop the compiler with error than be silent and
cause unpredictable or unexpected app behaviour in an unusual situation,
eg. normally responsive network/server is broken.

2. use a new timeout option name and avoid breaking/confusing existing
code.  Perhaps SO_CONNECT_RCVTIMEO?  This would only relate to the
connection process as opposed to normal processing.  The downside here
is that we need extra field in socket - is this too precious?

3. New function names eg. NutTcpTryAccept()  NutTcpTryConnect().  This
is simple but adds overhead, documentation and essentially they do
exactly the same thing so it smacks to me as more of a bodge than a
planned approach - one by one it is ok but when you add all the bodges
up together it gets to hard to manage/port and maintain.

4. Adding timeout parameter to the existing NutTcpAccept() /
NutTcpConnect() - with 0 for existing function - ie. no timeout.  Using
this later option will break code at the compiler stage, is easy to fix
and wouldnt cause unexpected results - unpredicted or unexpected results
are more evil that source code changes as the compiler points them out.
However, this would force almost every Nutos developer to change Their
source, probably as they are doing a major upgrade.  This is simplest to
code for as an application developer.

My vote is 2 or 4.  4 makes for easier code to read and manage. 2 makes
more sense for reduced impact to the community.  If we add more features
later, 2 is the better approach as we dont have to keep adding
parameters to the function call.


ps.  Henrik, could I trouble you to send me a copy of your patched
function to give me a head start - Im not on latest version so will need
to hand craft.

Cheers
Brett



Harald Kipp wrote:
> I understand your view in general, but we do not have NutTcpTryReceive()
> or NutTcpTrySend() either. Setting
>
>   NutTcpSetSockOpt(sock, SO_RCVTIMEO, &tmo, sizeof(tmo));
>
> affects the standard API call and it is difficult to explain, why
> NutTcpReceive() takes care of this option, but NutTcpAccept()
> ignores it and the user is forced to call NutTcpTryAccept() instead.
>
> Harald
>
> At 11:06 20.07.2006 -0300, you wrote:
>> From the API point of view, I actually prefer the former, because at the
>> first sight it's obvious that it has a different behavior. The
>> function name
>> expresses what it does, and that's what the API designer should
>> strive for.
>> Just my 2cents...
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>
>

--
-----------------------------------------------------------------
Brett Abbott, Managing Director, Digital Telemetry Limited
Email: Brett.Abbott at digital-telemetry.com
PO Box 24 036 Manners Street, Wellington, New Zealand
Phone +64 (4) 5666-860  Mobile +64 (21) 656-144
------------------- Commercial in confidence --------------------


_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion