[En-Nut-Discussion] NutTcpAccept() timeout

[Thiago A. Corrêa]

Hi,

If you go with the NutTryAccept method, you could make NutAccept() simply a
one line function that calls NutTryAccept( ..., 0 ); Then there is basically
no maintance/duplicated code overhead, and one generic function that deals
with both cases.
If you go with the ioctl option, I would suggest using two constants:
SO_CONNECT_TIMEO and SO_ACCEPT_TIMEO. It's some 2 fields more to the
structure, but can't we affort to use a few more bits?

Cheers,
  Thiago A. Corrêa

On 7/20/06, Brett Abbott <Brett.Abbott at digital-telemetry.com> wrote:
>
> 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
>