What is the fastest way to connect the same Rebol Application , running on two different computer over Internet ?
What is the fastest way to connect the same Rebol Application , running on two different computer over Internet ?
the fastest port connection for communication. example sharing the same data from a especial file. (synchronizing)
posted by: Mennohexo 18-May-2017/13:32:18-7:00
TCP and UDP are both available to connect over a network, but if you're behind a router, you'll need to open ports. What exactly are you trying to accomplish?
posted by: Nick 18-May-2017/20:58:56-7:00
1. have a rebol application with data i a file
2. available on two different WIN computers
3. every application should SEE the file data
of the other application
4. data should be updated in a file on the other
side
Yeah. thats it. a app to app communication path
posted by: Mennohexo 19-May-2017/3:00:22-7:00
Are the machines on the same local network or behind routers/firewalls on the Internet (your design decisions are not Rebol related)
posted by: Nick 19-May-2017/8:24:51-7:00
Also, if you're just intending to set up a simple file syncing service, that's one particular objective, but if your point is to share block(s) of data between multiple users, that can be handled with a better designed server solution: take a look at http://re-bol.com/rebol-multi-client-databases.html
posted by: Nick 19-May-2017/9:08:08-7:00
Here's a short example from http://re-bol.com/short_rebol_examples.r using the approach explained at the link above. You can connect many multiple clients at different IP addresses, to the single server:
R E B O L [title: "MULTI-USER Generic App SERVER"] write %iserve.r {R E B O L []
print "waiting..." nl: :newline p: open/lines tcp://:55555
forever [
if error? er: try [
probe cmmds: load data: first wait con: first wait p
probe rslt: mold do cmmds insert con rslt close con true
; save %d d ; commit data every s requests, or on timer, etc.
] [
er: disarm :er
print ne: rejoin [form now nl mold cmmds nl er nl nl]
write %server-err.txt ne close con
]
]} launch %iserve.r ; Eliminates the need for 3rd party database systems
R E B O L [title: "MULTI-USER Crud Client App Example"]
ip: "localhost" ; set this to the IP address of server machine
se: func [str /local er p st d n][ ; paste this generic function
st: trim/lines str
if error? er: try [
p: open/lines rejoin[tcp:// ip ":55555"]
insert p mold st d: first n: wait p close n close p return d
][
er: disarm :er
write/append %err.txt rejoin[now"^/"st"^/"er"^/^/"]
alert"*Network Error* Try Again" none
] ; send a "to-block" in the se command when returning a block
] ; send a 1 at the end of any se command that only affects server data
update: does [d: load se{to-block d}] ; run after updating server data
n: [foreach i[a b c][set-face get i""]focus a]
s: [se rejoin["save %d " mold d " 1"] alert"ok"]
x: [do z se rejoin[{repend d [} mold a/text mold
b/text mold c/text {] 1}] update do n]
y: [attempt[r: copy/part(find d: load se{to-block d}request-list""
extract d 3)3 repeat i length? j:[a b c][set-face get j/:i r/:i]]]
z: [se rejoin[{remove-each[i j k]d[i = }mold a/text{] 1}] update]
se{write/append %d "" 1} se{d: load %d 1} update
view g: layout[a: field b: field c: area across btn"New"[do n][do z do n]
btn"Save"[do x] btn"Edit"[do y] btn"COMMIT"[do s] btn"Raw"[editor %d]
]
posted by: Nick 19-May-2017/9:12:27-7:00
That framework consists of a generic server app, the generic 'se' function, which gets added to the client app code, and the minor code changes to the original (client) app code, as described in the comments. The original single user app in the example above is:
R E B O L [title: "Generic CRUD Data Storage/Retrieval Card File App"]
n: [foreach i[a b c][set-face get i""]focus a] s: [save %d d alert"ok"]
x: [do z repend d[a/text b/text c/text] save %d d do n]
y: [attempt[r: copy/part(find/skip d (request-list"" extract d 3)3)3
repeat i length? j:[a b c][set-face get j/:i r/:i]]]
z: [remove-each[i j k]d[i = a/text] do s] write/append %d "" d: load %d
view g: layout[a: field b: field c: area across btn"New"[do n]
btn"Save"[do x] btn"Edit"[do y] btn"Delete"[do z do n]btn"Raw"[editor %d]
]
posted by: Nick 19-May-2017/9:31:15-7:00
Thanks for that code examples.
I will start them.
My intention is a synchronizing.
Example :
- 3 rebol applications
- on different WIN computer internet
- every app has ONE file with relevant data
- the others have the name of the file in their
program code to get it.
- so a single application must get the 2 files
in synchronisation from the others
that's it.
The simplest direct port synchronisation can help.
So i will try your suggestions here.
WBR
Mennohexo
posted by: Mennohexo 19-May-2017/10:59:27-7:00
Hi again ,
oooops. look at his
R E B O L [title: "MULTI-USER Generic App SERVER"] write %iserve.r {R E B O L []
print "waiting..." nl: :newline p: open/lines tcp://:55555
forever [
if error? er: try [
probe cmmds: load data: first wait con: first wait p
probe rslt: mold do cmmds insert con rslt close con true
; save %d d ; commit data every s requests, or on timer, etc.
] [
er: disarm :er
print ne: rejoin [form now nl mold cmmds nl er nl nl]
write %server-err.txt ne close con
]
]} launch %iserve.r ; Eliminates the need for 3rd party database systems
Message :
Script Error: R has no value
** Near: R E B O L
>>
posted by: Mennohexo 23-May-2017/3:30:03-7:00
Sorry , the coorect message is :
Syntax Error: Script is missing a REBOL header
** Near: do/args script system/script/args
>>
posted by: Mennohexo 23-May-2017/3:31:38-7:00
The header of the script is written as R E B O L and not REBOL to facilitate the posting of the script, something easily overlooked. Remove the spaces.
Is direct file sharing a security risk? Don't really know. If ports are opened, what prevents others from using them?
Would exchanging data through an intermediate site or host with http and/or ftp, or even as email messages be safer? The data itself would be open to interception, but if encrypted, might be secure. There would be a slight delay, but maybe not a deal killer.
posted by: Bjorn 23-May-2017/6:53:25-7:00
My first 2 questions here were about the environment, for both technical and security reasons.
Controlling access to network connections is a fundamental design decision. Sending data over sockets with Rebol is no more or less secure than with any other language/tool. Anyone using a sniffer can capture data passing through a network connection which relays packets you've sent, whether they were sent using FTP, email, or any other protocol. And I expect that adding an intermediate remote host may potentially add even more points of access. I'm not a security expert, but you can find some collected examples about how to use encryption features included in Rebol, here:
http://business-programming.com/business_programming.html#section-16.30
An interesting side note: one thing which has been true for Rebol users, because it's not as popular as other languages, is that we enjoy a measure of security by obscurity. I hate the thought of having any PHP running on any Apache server, because those scripts are such popular targets. Also, not using any MySQL or other popular RDBMS eliminates the risk of all sorts of SQL injection attempts.
posted by: Nick 23-May-2017/7:36:05-7:00
Hello Nick ,
ooooops. R E B O L
of course.
This must have been a "drunken programmer".
Indeed text formating error from saving format.
For port security i recommend SterJONetstalker
comparing ALL rules and outgouing traffic by rules.
Yes , i agree that direct port sending is the same security level as other protocols if the data is
encrypted before.
Thank you for the examples.
Now. Second start here.
posted by: Mennohexo 23-May-2017/9:50:45-7:00
Long story, computer insecurity. https://cr.yp.to/ftp/security.html makes the question of an intermediate more of a question.
Can REBOL identifiy the connecting IP address?
Ports always gets me wondering. https://superuser.com/questions/82488/why-is-it-bad-to-have-open-ports has some interesting comments. Encryption mitigates the data theft issue, but...malicous code insertion?
posted by: Bjorn 23-May-2017/20:32:46-7:00
By writing the server code which evaluates incoming code, (ourselves, as opposed to relying on 3rd party libraries and more complex systems), we can more specifically choose how to evaluate incoming code. We can choose to only evaluate properly encrypted requests in the first place, or traffic which only comes from a particular IP address to which we share a round-trip connection (server connection on the client side is one way to validate an IP address, for example). The entire 'framework' above is just a few lines of code. You're in control of everything, from the data structures to what pieces of code run on the client vs. server, etc. You can (have to) extend this simple system's functionality as you need. No more and no less. To me, this is one of the most appealing characteristics of working with Rebol - composition tends to be more common than using piles of 3rd party tooling. Designing simple solutions from the ground up, rather than using small parts of large complex/unknown libraries. You're responsible for the design, but that design tends to be simple to keep in view and under control.
posted by: Nick 23-May-2017/22:48:56-7:00
For example, the first thing that made sense to me above, to validate an incoming IP, would be to connect back to them. That's incredibly simple to implement, and no built-in feature needs to be included in a server system to enable that validation (it's trivial to include a few lines of code which start a full server (even one which runs in a totally separate async process), directly in your client code). It's a solution which is composed - made up of basic capabilities which are easily put together. I find myself designing solutions in that way, far more often than searching for pre-existing solutions, when I work with Rebol (more so than when I use other tools).
posted by: Nick 23-May-2017/23:14:48-7:00
I hadn't read your links before posting my response. Here's a quote from the #1 highest rated answer in your second link:
"To address your question about why people can't just write software that isn't exploitable:
This is fairly easy for simple programs, but many programs that require a socket are complex. As such, they have many components, many of which aren't even written by the developer most likely (included libraries)"
Which was exactly my point.
posted by: Nick 24-May-2017/5:38:40-7:00
Moreover, your first link is specifically about FTP protocol. The framework above allows you to design your own handlers without any 3rd party protocol above the TCP layer (and as mentioned, you can also use UDP). Do that, and you're creating your own server directly from socket connections - not only eliminating potentential threats caused by 3rd party server software and libraries, but also the potential for attackers to take advantage of well known exploits to even the very protocols upon which they're built. So, that article also directly supports the tiny framework approach described above.
posted by: Nick 24-May-2017/5:45:48-7:00
If you're designing a system that manages data critical to national security, you won't locate the server on a street corner where anyone can access it, or give keys to locks on the physical server room to a criminal, or run your software on some Hostgator shared server, or use FTP to transfer files, or use any well known PHP scripts to implement any part of the solution, and most likely you won't even use Apache, MySQL, (let alone PHP), etc., anywhere in the mix. The more control you have over every part of the system, from the hardware up, and the simpler it is to keep the entire code base fully in view, easily understandable and under control by one person (or by everyone in the team involved), the more secure the design of that system can potentially be (as long as that one person/team and their actions are reliable and secure, of course).
If I'm uploading transient files to a computer system which stores absolutely no critical data whatsoever, then using FTP (third party server hardware and software, PHP scripts, etc.) isn't as much of a problem.
Building a server using the ridiculously simple framework above, and any other attachment to it which is constructed from the ground up, in a way that is natural, simple, fast, productive, etc. in Rebol, inherently provides more potential control over security than using layers upon layers of 3rd party solutions, as is the expectation with other more popular and complex development systems. Of course, it's then your responsibility to be aware of your own security requirements, and to handle them appropriately and responsibly, but that's much easier to accomplish when you have a complete view of every component in the mix.
posted by: Nick 24-May-2017/7:01:31-7:00
Huge discussion about secure data transfer.
I have heared about sFTP instead of FTP.
a SSH feature.
Have you heared about that damn thing ?
WBR Menno
posted by: Mennohexo 24-May-2017/11:53:19-7:00
Regarding the above question about sftp, I can't tell it this is on-topic or off. It is NOT related to connecting REBOL scripts over the internet, but it IS related to using REBOL to do secure ftp. I had to do this at work and wrote a REBOL program to call a secure ftp client called winscp. The program is available for examination or use here:
http://www.cobolrebol.com/pages/freestuff/Winscp.r
Coding style is to too REBOL-ish, but I still am in the beginner phase.
posted by: Steven White 25-May-2017/9:05:35-7:00
SFTP is ftp over SSH. Not really feasible using Rebol unless you're going to also write your SSH client. FTPS which is FTP using secure sockets should be easily enough. I would guess just change to using tls instead of tcp.
posted by: Graham 25-May-2017/22:30:49-7:00
Very interesting comments Nick. There have been a few complex systems cobbled together here that have either failed or were never even completed - at fantastic costs. One recently was a spend of a hundred million of dollars - for nothing.
Another was so stuffed up, its still not completely rectified, 1.2 billion dollars and 10 years on. Half a dozen hospital record systems were just taken out after cobbled Wanna Cry security patches were installed. How many more of these debacles are there around the world?
Perhaps most could have been averted with REBOL's fight against software complexity philosophy.
posted by: Bjorn 28-May-2017/7:18:50-7:00
There was Rugby4, have not tried it myself yet.
http://www.codeconscious.com/rebol/articles/introducing-rugby.html
posted by: Howard 10-Jun-2017/9:54:53-7:00
|