[En-Nut-Discussion] NutTcpAccept() timeout
Thiago A. Corrêa
thiago.correa at gmail.com
Thu Jul 20 22:25:45 CEST 2006
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?
Thiago A. Corrêa
On 7/20/06, Brett Abbott <Brett.Abbott at digital-telemetry.com> wrote:
> 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.
> 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
> >> 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
More information about the En-Nut-Discussion