Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: [Patch] Write data if socket allows it
Home

[Freeciv-Dev] Re: [Patch] Write data if socket allows it

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv development list <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] Write data if socket allows it
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 22 Aug 2001 18:43:45 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Mon, Aug 20, 2001 at 03:30:20PM +0200, Raimar Falke wrote:
> On Sat, Aug 11, 2001 at 12:49:32PM +0200, Raimar Falke wrote:
> > 
> > It can happen that in the send_buffer still holds data if something on
> > the client send a lot of packets in a short time and than waits for
> > data from the server.
> 
> Never sent a patch if you are busy. The long description of the above
> goes like this:
> 
> First the current situation:
>  - every send_packet_* method calls send_connection_data
>  - send_connection_data will add the data to the buffer and will call
>  flush_connection_send_buffer_* which will call write_socket_data
>  - write_socket_data will test if the socket is writable:
>     * if it is writable it will send as much data as posible till the
>     socket becomes unwritable or all data got sent
>     * if the socket is not writable it will just return
>  - the main loop of the client is in input_from_server and it will
>  just read data from the server
> 
> Problem: if in a short time a lot of data (it doesn't matter if these
> are a lot of small packets or some big ones) is send (via
> send_packet_*) and the socket isn't writeable the data is put into the
> buffer. If now the client wait for input from the server the data in
> the send buffer will never be delivered to the server although the
> socket may have become writeable.
> 
> Solution: in the main loop check if there is data to be sent. If so
> also wait for the socket to become writable and write data if the
> socket accepts data.
> 
> This problem isn't triggered in normal client operation since the
> human player is just too slow. The attribute block however can grow
> larger than 64kb and is send in 2kb packets to the server in a very
> short time.

As Vasco pointed out the network code aren't allowed to block since
the gui has to continue. The current solution is bigger than expected
but necessary IMHO.

For reproduction issues I have also attached a patch which shows the
problem. Just apply, set pingtimout to a high value and press turn
done at the client. The unit will continue to blink but the year won't
change.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Only one human captain has ever survived battle with the Minbari
  fleet. He is behind me. You are in front of me. If you value your 
  lives, be somewhere else."
    -- Ambassador Delenn, "Severed Dreams," Babylon 5

Attachment: extra_write_problem.diff
Description: Text document

Attachment: extra_write2.diff
Description: Text document


[Prev in Thread] Current Thread [Next in Thread]