World: r3wp

Pavel, about bug #1399, we need to dig deeper to get a more accurate 
report for Carl, so he can fix it quickly. Which file transfer example 
are you talking about here?

http://www.rebol.net/wiki/Port_Examples-> 4.4 Transfer a large file

I do get interruptions during transfer here, but they are not reliable 
in size.

In my machine this happen at the same point each time single client, 
but originally I've found this when I run 2 simultaneous clients 
with different large files (my was 50 and 100 MB)

Anyway I'm glad to you acknowledged the bug. Together with bug #1367 
and unsure garbage collection this prevents to build reliable (even 
simple) TCP servers.

I don't think this is the same bug. I get different interruptions 
and no stack overflow.

Anyway, there's a lot to dig through here.

#1367, why this one ?

(sorry, forgot to mention that I didn't get a stack overflow)

Sorry Typo #1369

Henrik, i guess  your case  is covered by #1369 aswell

I only use a single client/server.

The difference is that #1399 breaks even if single client is running, 
I've observed that filetransfer goes parallel even for some time 
(but not finish) when two clients was run. So the difference was 
mutual block happen after some time. (Henrik you are quicker in typing")

Pavel, what happens for me is that:

1. I start the server and it waits like it should

2. Then I start the client and transfer begins. At some point around 
10-20 MB in, the server just stops and the client returns to console. 
After a few seconds the server also returns to the console.

3. If I then start the server again, the read continues for another 
80000 bytes, like this:

>> do %/c/serve.r
Script: "Untitled" Version: none Date: none
subport read
len: 32000 total: 19192000 of 406258740...read
subport read
len: 32000 total: 19224000 of 406258740...read
subport read
len: 9000 total: 19233000 of 406258740...read
subport read
len: 7000 total: 19240000 of 406258740...read
subport close


And then the port closes and the server quits again, unless I start 
the client.

Windows platform?

yes, XP under Parallels.

Mine last three server messages:

len: 20000 total: 4260000 of 51923978
subport read
len: 20000 total: 4280000 of 51923978
subport read
len: 20000 total: 4300000 of 51923978

And client:
send: 20000 bytes
wrote
send: 20000 bytes
wrote
** Internal error: stack overflow

** Where: either switch applier wake-up loop applier wait send-chunk 
either switch applier wake-up loop

er switch applier wake-up loop applier wait send-chunk either switch 
applier wake-up loop applier wait

ier wake-up loop applier wait send-chunk either switch applier wake-up 
loop applier wait send-chunk eit

op applier wait send-chunk either switch applier wake-up loop applier 
wait send-chunk either switch app

t send-chunk either switch applier wake-up loop applier wait send-chunk 
either...
>>

Server stops smoothly after pressetted timeout

hum, i tried the ping-pong example  with 3clients and I don't have 
this bug, did you modified the client in some way Pavel ?

especially the send-chunk function which seems to do some recursive 
stuffs

Steeve I've mentioned large file example with server/client not modified,

let's be sure we're all running the same examples. The one in bug#1369 
is not the one Pavel is referring to, as far as I can tell.

The thing i can say after inspecting the source, is that it's not 
adapted to have several clients.

The clients are not waiting for any response from the server after 
sending each chunk.

So that, the server could be stucked with massives waiting chunks 
in memory

Steeve pls look up one page we are using single server single client 
large file example

Well, my remark stay relevant.

Because  if for any reason the server is slower than the client, 
a lot of chunks can be stacked in the server's memory

Pavel is referring to this example:

http://www.rebol.net/wiki/Port_Examples#Transfer_a_large_file

Guys, I know that well, just read what i say

it's not adapted to have several clients
 <- but why do I get problems, then?

it's not the only one problem, all the chunks are sent in one massive 
request before the server treat them, i guess

can you just  change this function:

send-chunk: func [port file /local data] [
    append clear data read/part file 20000
    if empty? data [return false]
    print ["send:" length? data "bytes"]
    write port data
    read port
    true
]

just an idea, not tested

sorry, it's wrong, cause data is local.
I should make my tests first

Guess i'm stupid, the problem is really simple.
there is a timeout both in CLIENT and SERVER.
after 10 seconds both server and clients are stopped.
(check the wait command at the end of the scripts)

That's for Henrik's problem.
I don't have the stack overflow bug

doh... it's even written in a comment. :-)

:)

I suggest that the wait is done in a different way in the example, 
otherwise the example is not very useful, I think.

removed the wait, and it transfers perfectly.

Where you removed wait Henrik?

oops, not the wait, just the 10 near the bottom of both scripts.

Sorry to say that but still the same in my machine 4'300'000. But 
when you are happy it must not be generall bug.

well, we still need to figure out what goes wrong. do you start the 
client or the server first?

We know what's going wrong.

The write function (in the send-chunk function) triger a WROTE action 
immediatly without returning in the waiting process before.
To me it's a system bug, probably linked with the OS used (XP).

check the version of R3 u use too

A96

not you, Pavel

Pavel use XP, i guess only XP has this bug

I guess my version would be important too, if I don't experience 
the bug :-)

and I use XP as well and I don't have the bug.