1. FakeThreads-Server
>From my web site you can get a working version of my fake thread
library,
which abandoned the mutex/shared memory idea and uses a server to
handle shared
variable requests. It works, and it is my hope that it will be useful
for someone
one day. Also I'm working on EParts, a library which is based on RDC,
but
allows multiple servers and well as multiple clients, and eventually
peer-to-peer
calling of routines instead of just having clients call one server, as
RDC is now.
BTW, I am uploading my FakeBind package to my site right now as well.
Any comments?
jbrown
--
http://fastmail.fm - the way email *should* be
2. Re: FakeThreads-Server
On 15 Aug 2002, at 19:17, jbrown105 at speedymail.org wrote:
>
> >From my web site you can get a working version of my fake thread
> library,
> which abandoned the mutex/shared memory idea and uses a server to
> handle shared
> variable requests. It works, and it is my hope that it will be useful
> for someone
> one day. Also I'm working on EParts, a library which is based on RDC,
> but
> allows multiple servers and well as multiple clients, and eventually
> peer-to-peer
> calling of routines instead of just having clients call one server, as
> RDC is now.
>
> BTW, I am uploading my FakeBind package to my site right now as well.
> Any comments?
About using sockets, yeas, a biggie: do NOT use if you are not behind a
firewall, or without password protection and ip verification in your Eu code.
Opening a port for anyone to access is like handing your keybd to strangers.
The http://www.rapideuphoria.com/mirc.zip shows how to add Eu threads to
mirc. The same can add threads to Eu itself.
Kat
3. Re: FakeThreads-Server
On 0, Kat <gertie at PELL.NET> wrote:
>
> On 15 Aug 2002, at 19:17, jbrown105 at speedymail.org wrote:
>
> >
> > >From my web site you can get a working version of my fake thread
> > library,
> > which abandoned the mutex/shared memory idea and uses a server to
> > handle shared
> > variable requests. It works, and it is my hope that it will be useful
> > for someone
> > one day. Also I'm working on EParts, a library which is based on RDC,
> > but
> > allows multiple servers and well as multiple clients, and eventually
> > peer-to-peer
> > calling of routines instead of just having clients call one server, as
> > RDC is now.
> >
> > BTW, I am uploading my FakeBind package to my site right now as well.
> > Any comments?
>
> About using sockets, yeas, a biggie: do NOT use if you are not behind a
> firewall, or without password protection and ip verification in your Eu code.
> Opening a port for anyone to access is like handing your keybd to strangers.
>
> The http://www.rapideuphoria.com/mirc.zip shows how to add Eu threads to
> mirc. The same can add threads to Eu itself.
>
> Kat
>
Can I get it to work for Linux? My FakeThreads-Server package is
Linux-only
(It may work for FreeBSD tho) while your package looks like its
Windows-only
(I assume from the presence of Win32Lib). I agree that my method is not
secure,
but the port which is used is chosen randomly and can not be known
ahead of time,
and nmap, a portmap scanner, appears not to be able to find the port
which my
threads server connects to. This makes is unlikely that someone will be
able to
break in (I agree its not 100%, but it does pose a formidable barrier).
Also,
any Linux user with a direct connection to the internet will be running
some
sort of firewall, unless they found some way to connect their system
without
running any servers. That said, using sockets for a program designed to
work
locally is a bad idea, but I was stuck with getting mutexes to work (it
appeared
that multiple programs would access the database anyways an corrupt
it).
jbrown
--
http://fastmail.fm/ - Access your email from home and the web
4. Re: FakeThreads-Server
On 17 Aug 2002, at 18:51, jbrown105 at speedymail.org wrote:
>
> On 0, Kat <gertie at PELL.NET> wrote:
> >
> > On 15 Aug 2002, at 19:17, jbrown105 at speedymail.org wrote:
> >
> > >
> > > >From my web site you can get a working version of my fake thread
> > > library,
> > > which abandoned the mutex/shared memory idea and uses a server to
> > > handle shared
> > > variable requests. It works, and it is my hope that it will be useful
> > > for someone
> > > one day. Also I'm working on EParts, a library which is based on RDC,
> > > but
> > > allows multiple servers and well as multiple clients, and eventually
> > > peer-to-peer
> > > calling of routines instead of just having clients call one server, as
> > > RDC is now.
> > >
> > > BTW, I am uploading my FakeBind package to my site right now as well.
> > > Any comments?
> >
> > About using sockets, yeas, a biggie: do NOT use if you are not behind a
> > firewall, or without password protection and ip verification in your Eu
> > code.
> > Opening a port for anyone to access is like handing your keybd to strangers.
> >
> > The http://www.rapideuphoria.com/mirc.zip shows how to add Eu threads to
> > mirc.
> > The same can add threads to Eu itself.
> >
> > Kat
> >
>
> Can I get it to work for Linux? My FakeThreads-Server package is
> Linux-only
> (It may work for FreeBSD tho) while your package looks like its
> Windows-only
> (I assume from the presence of Win32Lib).
Correct, mirc is windows-only, i pleaded with Khaled to make it run on winCE
for palmtops, he declined. I hear it runs about half way on Wine on *nix, but
the win32lib won't, of course. BUT, you can use the win code on a winbox,
and interface to one of the *nix packages (in the archives) on a *nixbox.
> I agree that my method is not
> secure,
> but the port which is used is chosen randomly and can not be known
> ahead of time,
> and nmap, a portmap scanner, appears not to be able to find the port
> which my
> threads server connects to. This makes is unlikely that someone will be
> able to
> break in (I agree its not 100%, but it does pose a formidable barrier).
Depending on how you did the nmap, if you did it on yourself, on the same
box, it's invalid. The socks layer will short-circuit the probes, and you cannot
see yourself from outside the box. The probes won't leave the internet side of
the socks layer and re-enter. You may not get a real picture with nmap on a
lan either, depending on permissions on the lan router or ip mapper. You
should run the nmap from outside your system.
> Also,
> any Linux user with a direct connection to the internet will be running
> some
> sort of firewall, unless they found some way to connect their system
> without
> running any servers. That said, using sockets for a program designed to
> work
> locally is a bad idea, but I was stuck with getting mutexes to work (it
> appeared
> that multiple programs would access the database anyways an corrupt
> it).
Actually, i considered sockets as a great idea, since on a lan you can mix
OSs and any type of hardware you can get. Also, you can run several
routers, and put a box outside the protected zone, accessable to the internet
for serving or fetching, and a beowulf on the inside, protected. The
disadvantage to DDE or shared memory is that is cannot be shared with
other puters, altho it's very secure on that one puter from interference of
another puter. With sockets, you code protection into the socks interface
you write, giving read/write permission as needed.
I was at one time, years ago, trying to get a team together to run a dedicated
box on my isp's lan. The idea was to put a box there running nix, and a
dedicated line back here, where i could add any scripting and database and
puter array that i wanted to. I won't bore you with the number and ways i was
let down, or the amount of opportunities to do non-normal webhosting that
passed me by since then.
Kat
5. Re: FakeThreads-Server
On 0, Kat <gertie at PELL.NET> wrote:
>
> On 17 Aug 2002, at 18:51, jbrown105 at speedymail.org wrote:
>
> >
> > On 0, Kat <gertie at PELL.NET> wrote:
> > >
> > > On 15 Aug 2002, at 19:17, jbrown105 at speedymail.org wrote:
> > >
> > > >
> > > > >From my web site you can get a working version of my fake thread
> > > > library,
> > > > which abandoned the mutex/shared memory idea and uses a server to
> > > > handle shared
> > > > variable requests. It works, and it is my hope that it will be useful
> > > > for someone
> > > > one day. Also I'm working on EParts, a library which is based on RDC,
> > > > but
> > > > allows multiple servers and well as multiple clients, and eventually
> > > > peer-to-peer
> > > > calling of routines instead of just having clients call one server, as
> > > > RDC is now.
> > > >
> > > > BTW, I am uploading my FakeBind package to my site right now as well.
> > > > Any comments?
> > >
> > > About using sockets, yeas, a biggie: do NOT use if you are not behind a
> > > firewall, or without password protection and ip verification in your Eu
> > > code.
> > > Opening a port for anyone to access is like handing your keybd to
> > > strangers.
> > >
> > > The http://www.rapideuphoria.com/mirc.zip shows how to add Eu threads to
> > > mirc.
> > > The same can add threads to Eu itself.
> > >
> > > Kat
> > >
> >
> > Can I get it to work for Linux? My FakeThreads-Server package is
> > Linux-only
> > (It may work for FreeBSD tho) while your package looks like its
> > Windows-only
> > (I assume from the presence of Win32Lib).
>
> Correct, mirc is windows-only, i pleaded with Khaled to make it run on winCE
> for palmtops, he declined. I hear it runs about half way on Wine on *nix, but
> the win32lib won't, of course. BUT, you can use the win code on a winbox,
> and interface to one of the *nix packages (in the archives) on a *nixbox.
>
I'd rather not, as FakeThreads is designed to run threads on the same
computer (which is why inet sockets are a bad idea.) I'm looking into
redoing RDC.e with UNIX local sockets, but I'm not sure if that will
give
adequate protection. (I think local UNIX sockets (AF_UNIX) can be used
by remote UNIX machines, just as inet sockets (AF_INET) can be used
by remote machines, but I'm not entirely sure.)
> > I agree that my method is not
> > secure,
> > but the port which is used is chosen randomly and can not be known
> > ahead of time,
> > and nmap, a portmap scanner, appears not to be able to find the port
> > which my
> > threads server connects to. This makes is unlikely that someone will be
> > able to
> > break in (I agree its not 100%, but it does pose a formidable barrier).
>
> Depending on how you did the nmap, if you did it on yourself, on the same
> box, it's invalid. The socks layer will short-circuit the probes, and you
> cannot
> see yourself from outside the box. The probes won't leave the internet side of
>
> the socks layer and re-enter. You may not get a real picture with nmap on a
> lan either, depending on permissions on the lan router or ip mapper. You
> should run the nmap from outside your system.
>
Well I use a firewall, so almost all of my ports are blocked from the
outside.
Of course, its alwayss possible to bypass a firewall in theory.
> > Also,
> > any Linux user with a direct connection to the internet will be running
> > some
> > sort of firewall, unless they found some way to connect their system
> > without
> > running any servers. That said, using sockets for a program designed to
> > work
> > locally is a bad idea, but I was stuck with getting mutexes to work (it
> > appeared
> > that multiple programs would access the database anyways an corrupt
> > it).
>
> Actually, i considered sockets as a great idea, since on a lan you can mix
> OSs and any type of hardware you can get. Also, you can run several
> routers, and put a box outside the protected zone, accessable to the internet
> for serving or fetching, and a beowulf on the inside, protected. The
> disadvantage to DDE or shared memory is that is cannot be shared with
> other puters, altho it's very secure on that one puter from interference of
> another puter. With sockets, you code protection into the socks interface
> you write, giving read/write permission as needed.
>
Interesting idea, I may try out a RemoteThreads package designed
to allow programs to share "threads" over networks.
> I was at one time, years ago, trying to get a team together to run a dedicated
>
> box on my isp's lan. The idea was to put a box there running nix, and a
> dedicated line back here, where i could add any scripting and database and
> puter array that i wanted to. I won't bore you with the number and ways i was
> let down, or the amount of opportunities to do non-normal webhosting that
> passed me by since then.
>
And I shall not bore you by showing my sympathy, but I will say that
you
had yet-another-very-clever-idea-which-was-shot-down-for-most-likely-
ridiculous-reasons.
> Kat
>
jbrown
--
http://fastmail.fm/ - Consolidate POP email and Hotmail in one place
