Neil Nelson wrote:

> One option I suggested to Harold was that we get the author of WinSCP

> included in the project so that you would then not need to re-do his work.



I think that's a good idea. Atho the author could as well be a bit

'problematic' if we do not mannage to form some kind of agreement. But

worth a try of course.



> I realized yesterday, and have talked to Harold about it, that the dynamic

> IP management that I was going to put on my server or on centralized,

> fixed IP boxes could be done instead by the dynamic IPs, with perhaps

> a single bootstrapping fixed IP box when no other dynamic IPs computers

> were available to manage the dynamic IPs.



As I understand this, I have already noted that before. A fixed IP is

only required for the users to know what to type in when they connect.

It could as well be a dynamic IP, if the user knows it (for example, you

were connecting to my dynamic IP when I told you about it via e-mail).



> Implementing this dynamic

> and distributed kind of DNS would be a little complex, but I expect you

> would have some good ideas for it.  If you think it makes better sense

> to distribute the IP management in this way--it would minimize our

> expenses for the hardware support required and scale automatically

> so that we would not need to have a forward plan for implementing

> additional hardware according to some approximated increase in users--

> then it is an obvious function for your IOSC since you are already

> managing IPs there.



Each IOSC is a cluster of it's own, until it connects to another cluser

(another IOSC in that aspect), which is when all known IPs are

automatically exchanged.



All IP add and/or remove requests are crossposted to every member of the

cluster.



This basicaly requires each user to know at least one IP on which there

is another IOSC running. The connection order is not important (if C

connects to B and B connects to A, the result is exactly the same as if

C and B both connect to A or if A and B connect to C). 



As you mention DNS (Domain Name Service), I might note you here that

IOSC already has a type of Domain Name Service: Simply enter your Domain

Name into the "Node description" box. In the ideal version of course,

this one still needs to be debuged and upgraded to get this capability.



> What functions need to be separate, such as the encryption and file

> transfer, and what functions need to be included in your IOSC needs

> to be carefully considered.  It seems to me that you are looking at

> several functions that can be divided into: (1) network and program/

> process management and (2) chat-like and basic data Internet

> communication functions.



I suppose we'll stick those functions that are likely to be selected by

the user (like a browser is in Windows) into the function server and the

basicaly required stuff (textual communcation to users, echo request,

etc) as built-in.



> A program like WinSCP could either work in coordination with your

> program such that, e.g., your program could be a launching place for

> all IOS programs, or a program would be launched separately and

> then communicate with the IOS for Internet connection, IOS service

> allocation, and additional process management.



I think the second option is nicer here. IOSC is not made only for

running programs on remote computers, that's why we've got the other

protocols. IOSC is for running programs, when the location of the

program is not given. Ok, there might be a graphical interface to this

(currently, we've got the textual "function: parameters", which is not

that hard to use at all, but is of course only textual), but I don't

expect this to be connected to FTP if ever to be something built-in.



> The voice transfer function seems like a very smart idea.  I did a

> quick search at SourceForge and found two programs that may have

> code we could adapt: efone and telephonectld.  The first is more in

> our direction, and the second may be useless but may also have some

> ideas.  Though voice transfer has some technical points, I do not see

> any reason why we could not provide an ability in a reasonable time.

> Some quick research is required to get a working design together

> and to identify any source that can minimize development effort.

> Go ahead and quickly look at this, and I will give it a more detailed

> look after a bit.  And then once we have voice transfer, my prior

> direction of voice recognition would not be far behind.



I was thinking about the Record -> Encode -> Send -> Recieve -> Decode

-> Playback procedure, which is preformed block-wise and is not like a

phone, because it does not stream data. We could of course come up with

something that streams the sound transmition, but I have no idea how

could that be done on average PCs.



If we manage to get this in quality and pipe it trough SSH, it could be

a big seller bonus, because there is no other encrypted phone line on

this world. Bussiness meetings could be done over this phone as there

would be no chance of anyone tapping it (except the government maybe).



> Another function that fits in well here is ICQ.  It may be that we

> could write certain code/function blocks that could be applied to

> a variety of user functions such as chat, ICQ, and voice.



Hehe, IOSC already is much like ICQ, with it's IP list it provides a

good indicator of who is present (with node describtions in place, you

will see how supperior it is to ICQ) and the normal textual chat is in

place of course. It's even like IRC, because you can choose any number

of nodes from the list and form you-name-it chatrooms.







--



Don't feel bad about asking/telling me anything, I will always gladly

reply.



Digging for info? Try AI Meta Search:

Http://WWW.AIMetaSearch.Com



MesonAI -- If nobody else wants to do it, why shouldn't we?(TM)

Http://WWW.MesonAI.Com

