DLL's - Page 2

neoxed · 03-19-2005, 07:09 PM

If you want example sources on memory mapping in C check MSDN.

Ganymede is asking about a higher-level and simplified interface for other languages (C#/VB/etc).

ganymede · 03-20-2005, 04:05 AM

There is no way you can run a persistant connection unless you build a service application which maintains the connection... which makes it even more horrible because installing another service as well is just horrible. Currently i login run commands logoff. But as i said that is all performance related ... and performance is not a problem in todays computing.

mr_F_2 · 03-20-2005, 12:13 PM

Quote:

Originally posted by ganymede
There is no way you can run a persistant connection unless you build a service application which maintains the connection... which makes it even more horrible because installing another service as well is just horrible.

not true, a service isn't necessary to do this.
also, why is installing another service "just horrible" ... ?

i post this to correct your statement, and the 2nd half out of curiosity. it's not meant to be a flame.

SnypeTEST · 03-20-2005, 12:21 PM

you can have a persistant connection if its a dll

jron · 03-20-2005, 01:19 PM

c# and the .net libs rock my socks off. id love to code for io with it ;P

ganymede · 03-21-2005, 03:19 AM

if you guys know how to do it let me know.... as far as i know you cant. Well its actually a bit of a tricky one... Um i am not sure if you can because as far as i know a DLL needs a host app to run in hence its gotta be a blows app, a windows service ... but because of the way webservers work you going to loose the session on the next request because they are stateless... so the webserver could be host but connecting back up to the same session could be a pain but i will give it a shot.

Also i just realized you cant get half the information you need by parsing the server output - like the user limits line....

limits 0 0 1 2 5

i have looked in the doc and i cant find a command that will actually show you a users limits (specifically the no of logins allowed)

working on the DLL and the site will take me some time... but will continue posting stuff as i go along.

Again... this is not the BEST way to do things but it is a way...

All positive criticism is welcome.

ganymede · 03-21-2005, 04:11 AM

If you guys think a persistant connection is better... i dont mind writing a service app, that allows for .NET remoting.

Going to play around the static connections not 100% how IIS handles these thoughs... maybe it will persist the state through as it is in fact hosting the DLL.

SnypeTEST · 03-21-2005, 01:29 PM

well , I though that you built the HTTPD Server to begin with.. if this isnt the case then nevermind. Persistant connection wouldnt do much then, because it will only be active for the amount of time that the DLL is in use, approx the same amount of time it takes for your code to output the html page. Unless if you can load the DLL into the HTTPD so it can hold the instance.

Bah too sloppy...

AS for the DLL still I would try to make one persistant conneciton at the DLLMain Entry point because it has its advantages.

1. you won't have to login to the FTP for every function you have...
2. many people might wanna use the DLL to create an application (.exe) with other languages (BASIC/C#/C++). So there would be a true persistant conneciton here.

ganymede · 03-21-2005, 02:52 PM

no IIS hosted application... its gotta run .NET remmember.
Althought i think a DLL that runs on the server can have a static connection to the FTP and IIS will keep it going.

The other option is to have a DLL that can perform all the functions and then you just decide where you want it to be... but a DLL CANNOT run on its own, it must have a host app / thread hence a service or app

ganymede · 03-23-2005, 04:08 AM

Ok i have tested the DLL in IIS with some basic functionality, IIS keeps the connection open to the FTP and i now presist the connection to the FTP for running commands. (whatever account is used to connect to the FTP for this background processing i intend to remove from any listing that i display on the website so it doesnt clog it up)

?? I am not sure if i should create a timer in the DLL to maintain the connection by running PWD or other commands. as obviously if the FTP has a timeout it will drop my socket. (this will automatically reconnect on the next command, i kinda like it the way it is because doesnt mean its connected indefinitly)??

The following support exists in the Library at the moment:

1) Reading a configuration which will hold the FTP settings to connect to.
2) Choice of connecting to the FTP via SSL/TLS (for the paranoid..its on your own machine dammnit! he he he) etc or plain mode.
3)70%-80%% of all user related commands AddUser/DelUser/AddIP/DelIP/Credits/Flags etc.
4) Reading / Parsing of the Group and User Files.
5) Parsing of FTP stats from ioFTPD by running the STATS command on the FTP server returning a DataSet.

The HTTP GUI's that have been completed currently although some are being reworked:

1) Login
2) User Manager
3) Basic Menu / Master Page.
4)Basic stats, no graphs just output.

I can send a screenshot if anyone is interested.

Short Term Plans::

Finish the basic FTP functionality: Groups / FTP Settings and VFS
Build GUI's for the functionality

Long Term Plans::
Build an Installer / Customizer for IO which installs some scripts by default and has web GUI's to configure those scripts.

I work 12 hours a day so i dont have much time to work on this every night what can i say a consulting life style doesnt leave me with much time.

Suggestions / help would be appreciated if anyone is good at graphics or web design and wants to help pm me.
I am not the greatest coder if someone has suggestions in design that would also be appreciated.

Again suggestions are always welcome.

Thanx guys

Harm · 03-23-2005, 05:00 PM

This DLL and the web interface are great ideas.
I can only suggest NOOP to keep the connection alive instead of PWD or anything else.

ganymede · 03-28-2005, 05:39 AM

Ok a lot of the API functions have now been built.... Exculding Server management stuff like rehash / reload / and the INI file, thats going to be the next task - still trying to figure out a nice way to make the INI file editable specially to make it nice when adding all script configuration options later on.

Ok the images are not much but its a start on the GUI's - Bleh... GUI's take so long, specially if you trying to make them look half pretty... i still need a graphics guru to help out know anyone... let me know (even if its just to do the frameset onthe outside nicely).

I have included some text in the images explaining a few things so check those out.

On the TODO list:
1) Groups manager interface
2) A Wizard for groups and users, allows you to add users easily.
3) Graphs for the Stats ... stats looking shocking at the moment. I know there are a few guys out there who have scripts that output HTML Stats that are all pretty, if you guys know of any good Scripts that do HTML let me know maybe i can speak to the author and include it in this package as a pre configured setup.
4)Do the API for Server Management.
5) log viewer again i think i remmember seeing some HTML log viewers in the scripts (they'll have to be unregistered cos i am unregistered.)

I think its slowly getting there. If anyone can code in .NET well and wants to help maybe we can find something for you to do....like parse the system ini file or build some kind of api around that :P

Anyways guys check out the images, and enjoy.

Comments and feedback appreciated. If you think i am wasting my time... tell me that too

Pu$u · 03-28-2005, 08:41 AM

it seems to be very nice.

language support would be a great feature.

ganymede · 03-28-2005, 08:42 AM

when the tool is done, we can get people to translate different sections... for the API's and Site.

Pu$u · 03-28-2005, 10:16 AM

that's cool.

this project will rock.