r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 Schemes] Implementors guide

Graham
9-Jan-2010
[698x4]
both ...
where does all this tcp syn syn+ack and ack occur ?  Is it automatically 
done in the tcp device?
I think we should have a common way of tracing network functions 
.. like trace/net on
the R2 protocols use net-log so how about we do something similar?
Pekr
9-Jan-2010
[702]
we could rename this group to !REBOL3 protocols ... we have REBOL3 
back now ...
Graham
9-Jan-2010
[703x2]
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.
Henrik
9-Jan-2010
[705]
I can't even remember ever having to use active FTP, because passive 
didn't work. It's usually always passive that you have to use.
Graham
9-Jan-2010
[706x7]
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
Andreas, you have this 


		open?: funct [port [port!]] [
			open? port/state/subport
		]
recursive function
I guess it croaks after the 2nd call
This isn't of much use yet .. http://rebol.wik.is/Rebol3/Schemes/Ftp
Can login ... and switch to passive mode ...
It's not syncing correctly ... must be my state machine is confused
And wonder why I need to issue multiple reads to get all the data 
....
Andreas
9-Jan-2010
[713x3]
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
Graham
9-Jan-2010
[716x2]
the bounding = binding
Just tidied up my ftp skeleton ... why is that a wrote doesn't trigger 
the next event ?
Andreas
9-Jan-2010
[718]
hm, no idea, looks sane to me
Graham
9-Jan-2010
[719x2]
I was afraid of that ..
well, I can fix it by putting a wait 1 in the wrote event
Andreas
9-Jan-2010
[721x2]
sounds like an awful hack :)
so you're struck after write ftp ["PASV"] ?
Graham
9-Jan-2010
[723x2]
not stuck ... just at console
I have to a read after each write
Andreas
9-Jan-2010
[725x3]
yeah, i do that in the pop3 proto now as well
wouldn't even get the 'wrote event, otherwise
wait, i'll upload my current pop3 version
Graham
9-Jan-2010
[728]
so, with the wait 1 in the wrote block  I can do this

cmd: open ftp://ftp.compkarori.com
read cmd
write cmd [ "PWD" ]
read cmd
write cmd [ "PASV" ]
read cmd
Andreas
9-Jan-2010
[729x3]
i do the following: in the write actor, i do write + read
in the read actor, i do a wait
the wait in the read actor returns once the awake handler in the 
tcp subport returns true
Graham
9-Jan-2010
[732]
here's yours http://rebol.wik.is/Rebol3/Schemes/Pop
Andreas
9-Jan-2010
[733x3]
here's the current version: http://bolka.at/share/prot-pop3.r[temporary 
url]
which is heavily restructured, now also allowing you to use custom 
commands directly
write/lines pop3 ["TOP 1 10"]
to-string read pop3
Graham
9-Jan-2010
[736]
hehe .. you changed your mind!
Andreas
9-Jan-2010
[737x5]
sure :)
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
Graham
9-Jan-2010
[742]
how does this work?

switch event/type bind
Andreas
9-Jan-2010
[743x2]
the _only_ exception seems to be when the tcp port is not yet connected
then a read on the not-connected port raises an error, so in this 
case a simple wait is enough
Graham
9-Jan-2010
[745]
Yeah .. I think that is what I am observing ...
Andreas
9-Jan-2010
[746x2]
(i'll get to the bind in a second, bear with me)
the second observation is that the return value of an awake handler 
seems to have no effect at all on scheduling