<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>TCPNET: I can&amp;#39;t tcp_close() sockets with IE7</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/23081/tcpnet-i-can-t-tcp_close-sockets-with-ie7</link><description> 
Hi all, 

 
I am implementing a web server using the RL TCP/IP stack. I&amp;#39;m
using a web server from Allegro (RomPager), as opposed to the Keil
HTTP server, because I required SSL/TSL. 

 
I&amp;#39;ve got to the stage where the web server works through the Keil</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: TCPNET: I can't tcp_close() sockets with IE7</title><link>https://community.arm.com/thread/144494?ContentTypeID=1</link><pubDate>Thu, 13 Nov 2008 04:01:45 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:97de75cb-d2a3-4fcf-a2f0-5967d312aa83</guid><dc:creator>Catcus Blip</dc:creator><description>&lt;p&gt;&lt;p&gt;
Trevor,&lt;/p&gt;

&lt;p&gt;
Thanks for your interesting post.&lt;/p&gt;

&lt;p&gt;
You wrote:&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;The Keil stack just returns received packets to a callback
function (so receive packets must be dealt with there and
then;...&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Well, I can only guess that Keil did that in order to save RAM
footprint while preventing the need to re-compile the stack if buffer
sizes change.&lt;br /&gt;
But I have no idea why they deviated from the common socket
interface.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: TCPNET: I can't tcp_close() sockets with IE7</title><link>https://community.arm.com/thread/142146?ContentTypeID=1</link><pubDate>Thu, 13 Nov 2008 03:54:42 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4a36ea7a-3476-4169-a645-635ae949f50c</guid><dc:creator>Trevor Page</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for your thoughts and ideas though - it&amp;#39;s much appreciated.
It would be nice to use a &amp;#39;nicer&amp;#39; solution if one exists.&lt;/p&gt;

&lt;p&gt;
The Keil stack is a strange beast really and took me a bit of time
to interface to the web server I&amp;#39;m using, which expects to see a
BSD-like interface. Furthermore it&amp;#39;s the first TCP/IP work I&amp;#39;ve ever
done and I&amp;#39;ve not actually done any WinSock programming at all,
although I&amp;#39;m familiar with the basics.&lt;/p&gt;

&lt;p&gt;
For starters I had to code a simple memory pool to store receive
packets as they come in. The Keil stack just returns received packets
to a callback function (so receive packets must be dealt with there
and then; Keil have implemented a flow control option to make things
easier). I then provide the buffers to the server through a
&amp;#39;recv()&amp;#39;-style wrapper function, and free up the buffers when the
server has transmitted its reply.&lt;/p&gt;

&lt;p&gt;
The other concept that I had to get my head around was how
listener sockets are used. With a conventional stack, I believe that
you only ever need to create one listener socket, and then calling
accept() will automatically assign you a new socket for each new
connection. But with the Keil stack, a listener socket becomes the
socket over which the connection is made. So you have to set up as
many listener sockets at the start for as many connections as you&amp;#39;ll
ever want.&lt;/p&gt;

&lt;p&gt;
Trev&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: TCPNET: I can't tcp_close() sockets with IE7</title><link>https://community.arm.com/thread/138953?ContentTypeID=1</link><pubDate>Thu, 13 Nov 2008 03:43:26 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b03321d3-528e-40e5-be91-d31a3ddf5c97</guid><dc:creator>Catcus Blip</dc:creator><description>&lt;p&gt;&lt;p&gt;
Trevor,&lt;br /&gt;
Indeed, I still haven&amp;#39;t started working with Keil&amp;#39;s TCP/IP framework
(but I will soon) so I don&amp;#39;t know the details. It is indeed
unfortunate that vital RFCs are not fully implemented, but after all,
they are still only &amp;quot;recommendations&amp;quot;...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: TCPNET: I can't tcp_close() sockets with IE7</title><link>https://community.arm.com/thread/130387?ContentTypeID=1</link><pubDate>Thu, 13 Nov 2008 02:56:44 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:bdd856d9-2d53-4b73-9874-ee70ead201f1</guid><dc:creator>Trevor Page</dc:creator><description>&lt;p&gt;&lt;p&gt;
I suspect that you&amp;#39;re not familiar with the Keil TCPNET TCP/IP
stack.&lt;/p&gt;

&lt;p&gt;
There is no such function as setsocketopt() with the Keil TCP/IP
stack, and there is no option equivalent to SO_REUSEADDR. The Keil
stack has a very simple interface and it doesn&amp;#39;t provide WinSock /
BSD style functions.&lt;/p&gt;

&lt;p&gt;
There are some timeout options in the keil Net_Config.c file. The
timeout options that I can find that are applicable to TCP are as
follows:&lt;/p&gt;

&lt;p&gt;
---&lt;/p&gt;

&lt;p&gt;
TCP_MAXRETRY :- How many times TCP module will try to retransmit
data before giving up. Default is 5.&lt;/p&gt;

&lt;p&gt;
TCP_RETRYTOUT :- If data frame not acknowledged within this time
frame, TCP module will try to resend data again. Default 4
seconds.&lt;/p&gt;

&lt;p&gt;
TCP_DEFTOUT :- Default TCP Socket Keep Alive timeout. When it
expires with no TCP data frame send, TCP Connection is closed.
Default 120 seconds.&lt;/p&gt;

&lt;p&gt;
TCP_INIT_RETRY_TOUT :- TCP initial Retransmit period in seconds.
Default 1 second.&lt;/p&gt;

&lt;p&gt;
TCP_SYN_RETRY_TOUT :- TCP SYN frame retransmit period in seconds.
Default 2 seconds.&lt;/p&gt;

&lt;p&gt;
TCP_CONRETRY :- Number of retries to establish a connection.
Default 7.&lt;/p&gt;

&lt;p&gt;
---&lt;/p&gt;

&lt;p&gt;
I don&amp;#39;t think that altering any of those configuration options
would resolve this problem. Again, the only option I can see is to
abort the socket if it &amp;#39;hangs&amp;#39; in a time wait state for too long.&lt;/p&gt;

&lt;p&gt;
Trev&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: TCPNET: I can't tcp_close() sockets with IE7</title><link>https://community.arm.com/thread/125025?ContentTypeID=1</link><pubDate>Thu, 13 Nov 2008 02:39:48 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:0449c559-fe6a-4277-bc7e-6e71b0724b38</guid><dc:creator>Catcus Blip</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;But what if the client NEVER sends back a FIN/ACK, resulting in
the socket remaining in time-wait state indefinitely after I have
tried to close it?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I believe that there is a setting in every TCP/IP stack to adjust
this timeout. I am not sure what the &amp;quot;recommended&amp;quot; value is (see the
respective RFC), but it should be in the magnitude of minutes, I
think.&lt;/p&gt;

&lt;p&gt;
about your server: you are always allowed to reuse a server&amp;#39;s
listening address without any problems. use &amp;quot;setsocketopt&amp;quot; with
&amp;quot;SO_REUSEADDR&amp;quot;.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: TCPNET: I can't tcp_close() sockets with IE7</title><link>https://community.arm.com/thread/118934?ContentTypeID=1</link><pubDate>Thu, 13 Nov 2008 02:27:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a2a252a2-9f65-4b78-bb71-eeada51f32df</guid><dc:creator>Trevor Page</dc:creator><description>&lt;p&gt;&lt;p&gt;
Yes, I understand that the socket closure process has to be
allowed &lt;i&gt;some&lt;/i&gt; finite time to complete, and I understand this is
the purpose of having the time wait states. So my server always tries
to properly close a socket first. After the socket has been told to
close, the server then continues to poll the socket state to ensure
it has gone back to being a listener.&lt;/p&gt;

&lt;p&gt;
But what if the client NEVER sends back a FIN/ACK, resulting in
the socket remaining in time-wait state indefinitely after I have
tried to close it? What other other choice do I have, other than to
abort the socket after a time-out of, say, ten seconds or a
minute?&lt;/p&gt;

&lt;p&gt;
Trev&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: TCPNET: I can't tcp_close() sockets with IE7</title><link>https://community.arm.com/thread/101266?ContentTypeID=1</link><pubDate>Thu, 13 Nov 2008 02:11:15 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:dade6497-1576-4808-ae7f-78cc61351356</guid><dc:creator>Catcus Blip</dc:creator><description>&lt;p&gt;&lt;p&gt;
Trevor,&lt;br /&gt;
what you describe is called &amp;quot;TIME-WAIT assassination&amp;quot;, and is highly
unadvised when writing correct TCP/IP software! the asynchronous
nature of TCP/IP networks allows packet to arrive at their
destination AFTER the connection was closed. the socket enters the
TIME-WAIT state to allow for such outstanding data to arrive, in
addition to allowing the possibility of the last FIN of the peer to
get lost (will be resent by the output window of the peer, but if the
socket is dead...)&lt;br /&gt;
never allow TIME-WAIT assassination!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: TCPNET: I can't tcp_close() sockets with IE7</title><link>https://community.arm.com/thread/76828?ContentTypeID=1</link><pubDate>Thu, 13 Nov 2008 02:04:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:10c64d2e-b9ee-4be2-abfe-01c4a516c86c</guid><dc:creator>Trevor Page</dc:creator><description>&lt;p&gt;&lt;p&gt;
I have resolved this problem and thought I&amp;#39;d put an update here in
case anyone else has this issue.&lt;/p&gt;

&lt;p&gt;
It later turned out that the third-party HTTP server I am using
already has a mechanism to &amp;#39;abort&amp;#39; a socket that remains in any of
the &amp;#39;time wait&amp;#39; states for too long (i.e. FIN-WAIT-1, FIN-WAIT-2,
TIME-WAIT). They implemented this because, from what I gather, it is
a fairly common thing for a socket to hang in a time wait state
indefinitely after the server tries to close it. So, the server
simply has to abort that socket if it doesn&amp;#39;t go back to the closed
or listener state after a defined time.&lt;/p&gt;

&lt;p&gt;
I originally thought that sockets hanging in the time wait states
(particularly when IE7 is at the client end) was something that I was
doing wrong, but evidently not.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: TCPNET: I can't tcp_close() sockets with IE7</title><link>https://community.arm.com/thread/52751?ContentTypeID=1</link><pubDate>Wed, 29 Oct 2008 11:45:22 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c159077e-0d1c-4327-8599-da287eb2d979</guid><dc:creator>Trevor Page</dc:creator><description>&lt;p&gt;&lt;p&gt;
I&amp;#39;ve now downloaded Wireshark and I can see exactly what&amp;#39;s going
on.&lt;/p&gt;

&lt;p&gt;
First of all, a useful reference: &lt;a href="http://kb.iu.edu/data/ajmi.html"&gt;kb.iu.edu/.../ajmi.html&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
With Internet Explorer 7, I see:&lt;/p&gt;

&lt;p&gt;
Keil Stack (server) -&amp;gt; IE7 (client) [FIN,ACK]&lt;br /&gt;
IE7 -&amp;gt; Keil Stack [ACK]&lt;/p&gt;

&lt;p&gt;
...and that&amp;#39;s it: IE7 does not send a [FIN,ACK] back to the
server. So in effect, IE7 allows the connection to remain half
closed. And this results in the socket sitting in the TCP_STATE_FINW2
(FIN-WAIT-2) state.&lt;/p&gt;

&lt;p&gt;
With Firefox, I get the full [FIN,ACK]..[ACK] happening in both
directions. Firefox properly closes its side of the connection
immediately, too.&lt;/p&gt;

&lt;p&gt;
So, I dunno - maybe I just need to put a mechanism into the code
that detects when the socket has been sat in FIN-WAIT-2 for far too
long and, if so, invokes a tcp_abort.&lt;/p&gt;

&lt;p&gt;
Trev&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>