World: r3wp

so you need to do a read port inside the read event?

yep

all this word overloading drives me crazy!

packet are append to port/data but the index is not moved

eh?

so how to read until there is no more data ?

no "eh?" me !!!
:-)

so the index is used by ??

there is no way to know how much packets can be received.
Your protocol has to send this info, if not you're tricked

why should every data be read first? Why is not 'read even triggered 
on new data arrival = change of buffer size?

actually the read function ask to the server to send the next packet 
to the client, if any.
You may receive a packet (event read triggered) or not.

Do we need to clear the port data after a read ?

or before a read ?

eg. copy port/data clear port/data read port ?

you do as you want

the packet is added to port/data

so if we 

copy port/data read port copy port/data .. we will get duplicate 
data ?

yes

ok.

so no more data is appended to the port/data until we ask for it 
using a read port

it's your duty to clear or remove/part data in the buffer

yup

My duty is clear ...

so with a write port ... the buffer is filled with my write data, 
it gets sent, and then cleared by the tcp device

no

write port data, can use any buffer

if you use the same buffer (ie port/data) for read and write, you 
may encounter some problems

i will not use the same buffer for read and write

I'm sure I read that write port uses the port/data as its buffer

no, the write function uses any buffer you want as parameter

because it's a parameted

*parameter

hm... I think we are not talking the same thing
http://www.rebol.net/wiki/TCP_Port_Details

says that the port/data is used by write

The details of the port actor for WRITE are:


   1. Set port/data to WRITE content (binary string) value. (Mainly 
   to keep it GC safe.)

   2. Obtain binary string as specified. The buffer is not copied. This 
   is a low level mechanism.
   3. Determine start position from index.

   4. Determine length from tail-index or from /part if specified.

   5. Set IO-request length and data. Zero the actual field (the length 
   actually transferred).
   6. Call the TCP device with the IO-request
   7. Check for errors

   8. Check for immediate completion. If done, set port/data to NONE.

So, this means that the port/data buffer is recreated on each read 
after a write

strange, you may be right

sometimes I am known to be right ....

not often ...

but it's sayed futher that the buffer is not recreated each time 
a read occurs

Check IO-Request connection flag. This is not a socket check, it 
is a request state flag check.
Check the port/data for an existing buffer.

If no buffer found, allocate one that is of the default size (32,000). 
Note: not 32K.
Compute buffer space available.

If available space is less than half the default size, extend the 
buffer.
Recompute buffer space available.

Setup the IO-request data and length fields. Data is the buffer tail 
position. Length is the buffer space available from above. Clear 
the actual field.
Call the TCP device with READ command.
Check result for error. If error, throw it.

so i think i got it.

it is saying it is recreated itf it does not exist

eg. after a tcp write

if there is sequential tcp read .. it does not recreate

seems a lot of gc must be happening at the tcp port

i wonder if the doc is up to date

I guess Carl has his reasons on doing it this way instead of having 
separate buffers for read and write

Have you fixed my ftp scheme so that it works properly yet?

who me ? I never say that

LOL ...