[En-Nut-Discussion] NutTcpAccept() timeout
Brett.Abbott at digital-telemetry.com
Thu Jul 20 21:34:09 CEST 2006
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.
> 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
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 --------------------
More information about the En-Nut-Discussion