World: r3wp

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 ...

needs a lot of work ... :(

read/write buffers are shared?

yes

seems to be according to the docs you linked to

i should make a try, i have some doubts

what is it good for? That way you have to read-out all data from 
buffer first, before you do "reverse" (read/write) operation, or 
you mess the data, no?

yes, copy all your data first before doing a write

store it in port/locals somewhere

it sounds to me as an unnecessary complication. I don't like it. 
But maybe Carl tried to create push on programmers, pushing them 
to do sequency of read/write correctly?

seems like a lot of overhead too ...

i tested. Alternating read/write causes the buffer cleared each times

so the docs are correct

But the buffer is cleared only after a write action occured .

If you receive several read events the data are added to the buffer 
(buffer not cleared)

Yep, I think that's what I said above

ok, i just confirmed it with tests

i encountered the famous stack overflow bug.

Never never use a [wait] when you treat an event in the awake handler

I see in Gabriele's prot-http he has an http-awake handler that creates 
events which he passes on to another awake handler

yes but it"s fake events passed from tcp port thru the fake http 
port.

Actually, it's just calling the event handler function of the fake 
port

it's not asynchronous

it's a pity that we have to "fake" these events, currently

I'd love to be able to pass "real" events on, WAKE-UP would already 
be there, but other stuff seems to be missing