Re: EU Server
Ralf Nieuwenhuijsen wrote:
> Cant we just have a sequence containing the Id's that are currently
> downloading. And then have a timed event. This was the 'host-user' could set
> either the cpu or the bandwidth, whatever is a bottleneck for him.
well, that is *extremely* inefficient. it creates the need for a timer
event for each user downloading, and those timer events begin to
collide and clash, asking for cpu time at the same moments and
leads to very poor downloads...
it would be better to hold a list of only those downloading, agreed.
then, we round robin those users. this may be more efficient as it
prevents
stalls and doesn't lead to the cpu having idle time when it should
be working. busy waits for timers to tick are bad bad form. it should
be used to process OTHER users who aren't downloading.
>>We would really need a companion client to do this efficiently...
>>a client that after it received that packet would send back
>>to the server a go/nogo signal for the server to loopback
>>into FD_READ and send the next packet/resend the last packet...
>Doesnt FTP do this ? Or maybe HTTP, this really doesnt make much
>difference for me. Just wanne be able to 'store' some 'downloadable' files.
we should be able to arrange that much easy enough...
i'm assuming you are talking about your bot match programs...
so you can have online 'fights'...
the EUServ should be easy to adapt for that... really easy...
especially if ALL users are there strictly to watch the fight...
otherwise, what you could do is make a new 'channel' for those
that wanna see the fight and have EUServ broadcast the fight as
it calculates the fight parameters during idle time. a timer
would be good here, as you could pulse once per second, calculate
the bots latest stats, broadcast their positions and 'hitpoints'
remaining over the new bot channel, and return to polling for
other events, like users whom are watching sending chats and
taunts as the bots fight :)
>>without a way to get triggered into FD_READ, we would need
>>to (somehow) scroll the entire userlist, often, and see
>>who is ready for their next packet/send them a packet/reset
>>their status to ready for another packet...
>We would only have to scroll through a list of 'currently downloading'.
>I was assuming the server was extremely 'branched' .. i.e. some sort of
>thread-based execution. I couldnt really see the problems above if so ?
unfortunately, you assumed incorrectly.
i fake, real well, thread based multitasking.
win32lib doesnt support threads, and i'm not real sure that even
if it does one day, that i will actually _use_ threading.
threading causes a lot of problems that don't seem real apparent,
and solve nearly 0 problems i am facing for any implementation
of EUServ i have thought of. threads can create very bulky
code, very slow code, because every time i need to update a user's
record of information, i have to determine if it's locked, lock it
if it isn't, place the request into a queue if it is, and once
its unlocked, then lock it, and FINALLY, get to perform my updating,
then unlock it, fetch the next in line in the queue, and start
all over again, before i can return to polling for new activity.
scrolling thru a list of currently DL'ing users, is indeed a viable
and plausible answer for part of this ftp implementation.
needing a client, custom built, would be not viable nor plausible.
so i keep trying to rule out needing a special client for ftp,
and when i do that, i remind myself that i desire to rule
out special software for *any* application of EUServ. :)
to sum up, don't worry to much about the ftp thing...
there will be an elegant and efficient solution to the dilemmas
i'm looking at with it, that will spring up and pop in my or
someone else's mind (who knows EUServ's code) and that'll be
the end of what is likely the hardest actual implementation
of an application for EUServ. i'm not convinced that popping
a timer that scrolls the list of current DL users is the answer,
and i haven't researched the FTP protocol enough yet to know
it's syntax for go/nogo/resend conditions as packets are transferred.
i'd like it to be able to use generic FTP software, just like it
can use generic telnet software now for 'chatting'.
>Yes, I would say that if some of the above problems are a 'true'
>problem, than the whole FTP thingie wouldnt be possible in any language.
>First of all, binary modes, there is some sort of 'check' byte every now
>and then, Im sure.
likely there is, indeed... see above... once i become more familiar
with the protocol, the answer will likely stare at me with a chesire
grin.
>However, if you know a more bandwidth friendly way. Lets do that.
oh absolutely... i'm looking to make this server, no matter what
its implementation, be *much* faster than any server for any specific
reason can hope to achieve... so far, that goal hasn't been all
that hard to achieve :) as the competition is rather... tortoiselike :)
>Actually I would even prefer if only those I gave a little program can acces
>it. Instead of all.
naturally. indeed, all files (if we implement an ftp server) will have
access priv encoded into user[trustlevelIDX]...
tis' why its there :)
a simple directory structure based upon trustlevel is all that is
required, and was thought of before I wrote EUServ... i only need,
for that aspect, to type in my 'notes' as it were... i've even
thought of a way to create bulletin boards (sticky notes?) wereby
you can leave messages for other users or just a specific user,
or leave a *file* for a 'set' of users (ergo:group) or even
a single user ONLY... all via simple directory structures...
> Like NetMeeting ? I think you pretty much need a *lot* of control over
> windows. Or did you mean: euphoria programs.
heh;)
all the above and no, i need no control to speak of :)
remembering that no special software will be needed, other than
telnet, and the server won't require anything other than
system() if need be, i can apply a few tricks i've learned as
an implementor for this that and the other, to make, if nothing else,
a solid, text based, page editing/code editing/code executing/bug
report back environment.
graphics may even become available, when i get this part working,
as i have a few theories about autoupdating someone drawing
something in ... oh... say 'paint' for example...
basically, i can see, especially at the beginning, the ability to
type a command to the server, and have the contents of your clipboard
dumped to those you are working with... this method would then
need no special client for everyone to have a 'true whiteboard'...
as for the rest... if you can type it, it'll be on-pecan.
the single document/multiple-user-editing-of-said-document
aspect of the collab tool, will be the part that i, myself,
actually care about...
pictures would be a pro-bono as far as *i* am concerned for the
collab i'll be doing... i need to be able to hash code back
and forth with people i'm talking to, and see that code running
on other machines for speed/debug testing...
>Hey feel free to make a new windows development environment
>including group collaboration, that would be cool.
well, if we aren't careful, we begin needing special clients...
i want to avoid that like a plague... i may wind up doing
just that, *as well*, to exploit more powerful features...
to me tho, there is nothing more irritating than "i have
MS netmeeting and you have netscape conference and those
wont talk to each other"...
> >the other thing i want to work on is finding EUserv a home,
> >where it's up 24/7, in the collaboration mode, ready to go,
> >for everyone on this list to use.
> >I think we could use this, as a group, and i think it would help.
> Any takers ?
ill add to that question:
any takers whose morality is without reproach or question? :)
--Hawke'
|
Not Categorized, Please Help
|
|
