| Age | Commit message (Collapse) | Author |
|---|
|
that were using fstring, I hope.
|
|
TcpSocket, fixed many other things, and finally removed ParamProc. Anything
that needs it will now have to switch to OptParser.
|
|
servers that run for weeks or more.
|
|
called compat. I've updated the linux and windows builds and it looks pretty
good. I also added a config.h file which we have to edit by hand until I can
work on build some more. Linux File operations now use 64 bit mode, windows
can't, or at least, I don't feel like researching it right now.
|
|
crater the server system. Lameness...
|
|
Myriad seems to work. I have to run it through a few more paces, and there are
some known corner cases that I may just disallow, such as too-small block sizes.
Beyond a little more testing, it's ready for production. I may switch some of
my cache tests to using it now.
|
|
onCloseConnection on each client before cleaning it up, allowing for smooth
cleanup. Later we may want to add a nicer version with a timeout for pending
data to be transmitted and the like. This one is pretty harsh.
|
|
copyright 2007-2008.
|
|
|
|
as includes go. This required a little bit of reworking as far as archive goes,
but I've been planning on changing it aronud for a bit anyway.
The final result here is that you may need to add some more includes in your
own code, libbu++ doesn't include as many random things you didn't ask for
anymore, most of these seem to be bu/hash.h, unistd.h, and time.h.
Also, any Archive functions and operators should use ArchiveBase when they can
instead of Archive, archivebase.h is a much lighterweight include that will
be used everywhere in core that it can be, there are a few classes that actually
want a specific archiver to be used, they will use it (such as the nids storage
class).
So far, except for adding header files, nothing has changed in functionality,
and no other code changes should be required, although the above mentioned
archive changeover is reccomended.
|
|
disconnected. It now automatically closes down the local end when the remote
end dies.
|
|
implement in Bu::ItoServer, but I'll get to it. Basically you can trigger a
"tick" any time you want and it will propegate as an onTick event to all active
clients. You can also have these generated automatically everytime the system
passes through a polling cycle. In this case, you should never ever write
data to the socket every tick. It will cause your program to go bursurk.
|
|
|
|
in the deconstructors. When you deleted a server it wouldn't close it's
sockets. We never noticed because servers normally last the entire lifetime
of the program they're in.
|
|
sever/client-link system.
|
|
|
|
done yet. The Client class now supports a function called getLink() which
returns a ClientLink object. This object may then be passed off to any other
class and called to send messages to that client object. It is threadsafe if
ItoServer is being used, and not for Server. Sending a message via a
ClientLink calls the onMessage function on the assosiated protocol.
Note that sending messages from within protocol event handlers or functions they
call, while safe, may be slow and it's reccomended that you avoid this.
|
|
|
|
has been fixed, it now safely disconnects after emptying the Client's outgoing
buffer.
Added some more helpers to Bu::FString.
Added the beginings of ProtocolHttp using a new method for processing protocols
that's based more strongly on an NFA state machine, this makes sense, but I
never had the desire to actually try implementing it before. It's working
pretty well.
|
|
compile under OSX. So far, no problems with anything else, it looks like build
and nango both build without problems, libbu++ is truly becoming a full cross-
platform toolkit.
|
|
the old one in pretty much every way, and better in most. It's much easier to
understand. And the atom class is better.
|
|
to include many more state indicators and caps queries, and everything is
working better in general.
|
|
I'm going to do it over from scratch, that was just painful. Also, started in
again on the server system, it's looking pretty good, already got connections
working, next up is managing data flow through clients and protocols!
|
|
actually interacting with clients, and the Client class is almost there, except
that it doesn't really do anything yet.
|
