Why not write a networking protocol that resembles scripting in Rev?
Make a library of it
requestsendfiletohost hostip,filepath
sendfile
cancelfilesend
receivefile
etc...
(dont limit it to sendstack...)
and it's not even complicated actually!!!
PC1
wait for call c on port p
validateuser/data = get file from me (pc2) with this id
go stack url pc2ipaddress:p
or
read from socket url blabla to url ("file:"&thisfilepath)
PC2
send call "get file from me..." to pc1ipaddress
open socket on port p with message sendfile to pc2 whatever...
on sendfile x
write to socket p url ("file:"&x) to pc2ipaddress
end sendfile
just off my head but it should work like a charm. There's a full example
Or the taoo way, all we need is:
1 stack in the backscript/stackinuse (the network manager) to monitor
network traffic or establish the connections. Much like I've seen with the
revChat stack. but as a library with a protocol language to exchange files,
scripts, information or objects in xml, etcml formats.
Naturally there will be issues as threading is still a dream in RunRev but
it allows the following doors to open if listening on multiple ports is not
viable:
Use multiple instances of RunRev to communicate across different ports with
1 or more portlistening runrev-instances. Transfer stacks to them to make
remote/distributed execution or send remote scripts/data (synchronicity and
security is an issue without or without threading). But i think i got a
quick solution for that - the roundrobin heartbeat method as it is known in
clusters.
Im certainly on this path at work (large server farm multi-site
LAN/SAN/NAS/WAN environment) to manage different servers without any NT
tools to depend on (they tend to break/change parameters depending on
windows versions). Although with windows base networking, transfering files
across the network is a simple as
get shell("robocopy \\server1\driveletterorsharename[$]\filepath.fileext \
\\server2\driveletterorsharename[$]\filepath.fileext " && \
myoptionswitcheswhichvaries[situationcontext])
xcopy, scopy, robocopy, xxxcopy (the best - 10 pages of switches for all
occasions - i have plans one day to write an interface for it for
synchronized copies but Robocopy has done the job so far.). One other thing
to know is regarding extra long file paths. Most copy programs will choke
and abort that file. It's good to keep logs. For extra long file path
xxxcopy or subst.exe (Net use only maps the share's root, subst can mount as
a drive any path in a shared resource.)
Using file sharing is so much simpler than with net use Franz. Although
there's performance hits depending on how you copy from where to where. If
you copy from server a to server c via server b (in rdp - terminal service
remote desktop p?) there will be a cached copy from a to b to c... Things to
know...
As you see, a one liner suffices for any occasion.
And all this i already have in an NTResKit library stack that handles
multiple shares, files, security and audit settings or permissions, log
errors parsing (and fixing), user-editing, etc etc etc that NT domain admins
do. Not free! But there's a couple simple examples on MonsieurX.com.
I've done all of it in MC with shell calls - never the RevTools. Having to
delete around 50GBs of files here and there using rev is unthinkeable... And
it doesn't support unc file paths //servername/share. Would this solve all
our problems? Send "script" to stack on //PCServer
I dont want to write externals because someone already wrote the wheel using
shell tools which i can launch and forget! (actually not a good idea to
forget unless you're sure nothing iwll break down in between - which happens
all the time!)
But for rev-networking, like the libURL code we enjoy so much, there's lots
of benefits to have it built in rather than use external tools.
For example, if the shell program stalls or awaits an answer, rev doesn't
know what to do... (besides the fact that your shell("start...") because
that too can fail (the directory being set for a non existent folder or
drive letter for example!
And there is still no timeout for any commands unless you trick Rev to do so
with a second instance of Rev that kills the first one if it stops
responding - round-robin cluster technique for better availability (google
it).
Also, some shells require interactive messages and we can't do that that I
know (like writting to the args[] or typing text into the shell (like the
message!).
"Net use" can block you this way btw if a password is required... Know your
switches!
All it takes is a little scratching to see all the problems and limits in
RunRev's current engine in this particular field.
But i'll be experimenting with that soon. We'll see:
SendObject hostobject, ascriptobject,
returnmessageandparametersinforequiredobject
In terms of long-term reliability, relying on other programs can create
issues of incompatibility with parameters or output which are also out of
your control but it does save a lot of time if you dont script it yourself.
Like i now know with my NT tools, that's just delaying the innevitable need
to write a real rev-networking protocol. Alas without threading, it's not
going to be "clean" at some point unless you use a shell program that can
deliver correctly or with the right features (xxxcopy, .
Wouldn't compileIt for RunRev be a good idea now? ;)
And now what? 4 days of intense scripting into taoo.
In the TAOO menu for this weekend theres a hint of
Roast of a network object manager, with a side dish of network object
browser, network master and template and agent bathing in a sauce of juicy
objects and GUI imbricated categories and finely grained verbs.
;)
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of sims
> Sent: Thursday, May 05, 2005 06:37
> To: How to use Revolution
> Subject: Re: Writing a file to another computer on the LAN?
>
> At 1:38 AM +0200 5/5/05, Malte Brill wrote:
> >Anyone an idea/link to a tutorial on how to set up an FTP
> server on Mac Os X?
>
>
> Google using "setting up ftp server on OS X" gave me the following:
>
> http://www.creativemac.com/2002/09_sep/tutorials/ftposx0209242.htm
>
> http://www.atpm.com/8.12/networking.shtml
>
> http://home.earthlink.net/~dgreuel/howto.html
>
> hth
> sims
> _______________________________________________
> use-revolution mailing list
> use-revolution@lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
