[En-Nut-Discussion] NutTcpAccept() timeout

[Brett Abbott]

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 --------------------