AltME groups: search

I can't write the pop scheme .. I don't have a pop account that isn't 
SSL :(

ah, yes, that may be a problem

You'll note that I have a local for state which is not used

whenever you set a new state, you'll have to do it via client/spec/state 
in any case

i'm already playing around with a pop scheme

wait 1 is a linux fix?

or a "+OK" or a "-ERR"

I see the top 10 lines and a "."

Just needs a little error handling ...

you send the command to the port and retrieve either a multi or single 
line response

Sure ... but then a new command comes along ...

hehe, i could abuse write/lines as indicator that a multiline response 
should be parsed

Normally you set a state so that your machine knows what to expect 
next

at present there's a finite set of commands :)

If you're retrieving a 20mb file via email, you really want to send 
each part back to the client as you get it and not just store it 
in locals as the original r2 pop scheme does.

I think we should have a common way of tracing network functions 
.. like trace/net on

Shame ... I quite like this group as is, ,but probably !REBOL3 network 
schemes is a better title.

Here's a reference for ftp client implementors http://cr.yp.to/ftp.html

Note that Bernstein recommends only using Passive mode as Active 
FTP is a security risk.

Certainly will make it easier to only support passive as then we 
don't have to open a listen port for an incoming server connection

graham, afaic open? should work as it is. as the actor functions 
are contained within a block, the bounding is left to make-scheme. 
and make-scheme leaves the inner open? bound to the system version

actually, that's a rather nice property of the whole actors-as-a-block 
model, that each call to read/write/etc within an actor function 
calls the system version of the word, not the actor version

on the other, things look a bit confusing, at first sight. open? 
being a prime example of this

Just tidied up my ftp skeleton ... why is that a wrote doesn't trigger 
the next event ?

well, I can fix it by putting a wait 1 in the wrote event

I have to a read after each write

in the read actor, i do a wait

and i even tested it with a win32 rebol3 :)

and one of the things i observed is that the tcp port does not seem 
to get re-scheduled after a write

i.e. i do a write on the tcp port, later on i wait on the tcp port, 
but no the wrote event never occurs

which lead me to conclude that if i want any network interaction 
to occur on the tcp port, be it sending data that was buffered with 
write earlier, or listening for incoming data, i have to tell R3 
that by doing a read on the tcp port

then a read on the not-connected port raises an error, so in this 
case a simple wait is enough

(i'll get to the bind in a second, bear with me)

but influences when a WAIT on the port will return

a WAIT on the tcp port returns once the awake handler returns true; 
for any other return value, the WAIT keeps hanging on

so in essence: write only buffers data to be sent, read schedules 
a port so that it awakes on events, wait blocks until awake returns 
true

need a diagram to understand this ...

i think you can easily cause a deadlock this way

WAIT on a port

the WAIT will keep on blocking, but the port was not re-scheduled 
with a read, so the awake handler will never be called again

yes, as a user :)

as a scheme author, we have to be careful to avoid those deadlocks

as a context. with the bind i can make those values appear as if 
they were local words, i.e. buffer refers to event/port/locals/buffer

when the second parameter to a function is more than 10 lines down 
the page ... .it escapes my eye!

very low-level, most of it a bit below our concerns :)

read reads a max of 32,000 bytes ... so does this mean if more data 
is coming, another read will be triggered?

A few issues a couple of years old http://www.rebol.net/wiki/Ports_and_Schemes:_Issues#Issue_4:_WAIT

Managed to get a directory listing with my ftp scheme :)

a directory is just a file .. so this means I have file transfer 
"working "

Just looking at what R2 does .. .each time it does a file/directory 
transfer, it opens the data connection, sends the command and then 
closes it again.

Hmm. I did a LIST and only got 4000 characters back.  I tried it 
again, but delayed the read a bit longer and got the full 8000 characters 
or so.  So, wonder why the data arrriving is not triggering the read 
event

http://rebol.wik.is/Rebol3/Schemes/Ftp
Updated ... I really need a rebol syntax formatter for this

This isn't going to work unless I queue the user commands and process 
them once a command has completed.

It works on my server, but I tried it on one of the linux distro 
sites and there it doesn't.... as my write commands are written to 
the port before the previous commands have completed.

Probably, we should think about a framework to build state machine 
oriented processes.
A new dialect ?

Gregg made a cool FSM dialtect years ago.

is there a trick to read R3 dns:// ?  I haven't found it.  Didn't 
see any tickets in cure-code.  Should something be submitted there? 
 (last year was 100% R2 product design...I am wanting to port some 
Core stuff to R3, but I need as much network stuff as possible.  
I did write a real-time video codec for R3 a couple years ago...I 
might see if it can hook into the new codec stuff, too.

There isn't a dns:// scheme written yet.

there is a low level dns lookup occuring in the tcp device ...

there is a dns://scheme but the usage is either unknown or broken.

so this is a r3 video codec?

To get the ip address I suspect all you have to do is do a query 
on a port once the lookup has completed

So how do I "query" a port?

my R3 need with DNS is to be able to tell if a domain is there or 
was it mistyped, to prevent calamity

in the awake handler, there is a 'lookup event

Now how to do a reverse dns lookup??

the above was a joke!  please ignore

IIRC we need UDP to do a DNS request.

Yeah .. just did a packet trace and it's all UDP

Steeve, what's the algorithm for reading data from a port when you 
don't know how much data is coming down?

Does each arrival of data trigger a 'read event?

but don't forget to execute a [read port] each time you received 
a packet , to be able to receive the futher one.

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

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 ?

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

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

because it's a parameted

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

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.

eg. after a tcp write

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

needs a lot of work ... :(

i should make a try, i have some doubts

yes, copy all your data first before doing a write

seems like a lot of overhead too ...

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)

i encountered the famous stack overflow bug.

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

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

but a WAIT on the scheme port never returns, even though the scheme's 
AWAKE returns true

the default timeout times out waiting for ftp.debian .. so I put 
a wait 10 seconds there!

I was trying to find a ftp site with a lot of data to read from ...

that should give you a huge directory listing :)

yeah ..doesn't get a complete directory listing ...

missing a read port in the read event

I can pick up the rest doing a 
read cmd

i just tried a bit from the console

client sends PASV, gets a port number, connects to that port

you'll have to do a PASV before each new request