sent over the IRC network. This makes it possible to fetch information
from remote servers that is not known locally, and also it makes it
possible to do more things, or do it easier.
This does require the remote servers to enable RPC as well, though,
eg: include "rpc.modules.default.conf";
(They don't need any listener or rpc-user blocks)
Code-wise it looks nice, like from rpc_server_module_list it is a simple:
/* Forward to remote */
rpc_send_request_to_remote(client, targetserver, request);
This is work in progress. In particular, there is no handling yet of
timeouts (eg if the request to the remote server, or the response
from it takes ages). Nor does it handle the case where the server
quits half-way through the request/response... that is: it does free
the request and such, but does not notify the RPC client about it.
That will need to be added, of course, likely soon.
Over the IRC network this uses the new RRPC command:
:<server> RRPC <REQ|RES> <source> <destination> <requestid> [S|C|F] :<request data>
A request looks like this (assuming it is short):
:001 RRPC REQ 001ABCDEF 002 abc SF :..this is the json request...
And then the response (assuming it is long) is like:
:001 RRPC REQ 001ABCDEF 002 abc S :..this is the json response...
:001 RRPC REQ 001ABCDEF 002 abc C :..more...
:001 RRPC REQ 001ABCDEF 002 abc C :..more...
:001 RRPC REQ 001ABCDEF 002 abc F :..and that was it.
There is currently no request/response limit, it is limited by memory.
Right now the only call using this is server.module_list when called
with a param of "server":"some.remote.server"
dbuf->length to be unitialized.
This wasn't an actual problem until yesterday in UnrealIRCd code,
since the whole client struct was initialized to zero, including
client->local->sendQ(->length) etc.
However, now we use the dbuf code elsewhere too (on the stack) and
3rd party modules can use it too, so fix this bug.
Such a variable suggests that we will never read past that, but that
is not the case, since we (correctly) assume that the buffer is
NUL terminated, which is ensured by dbuf_getmsg().
The 'length' is still available for informational purposes, to avoid
strlen()'s at various places.
Hm, I guess length can cause the same confusion as bufend, but still..
I like it better :D
This also includes buffer modifications to have a larger read buffer
and IRCv3 implementations (partial or not) for:
labeled-response, msgid, server-time, batch and account-tag.
As said, it is the initial and partial implementation.
There are still various FIXME's and TODO's, the API of various
functions may still change (actually that is true for the next
months, even) and some stuff is currently in the core that will
be moved to modules.
If BUFFERPOOL dbuf_put would return -1, but at some places !dbuf_put was used,
I've changed it so it will return 0 (so use !dbuf_put now, don't use dbuf_put(...) < 0 :P).
I also added some nice warning thing. I couldn't send from the send routine because that's risky ;).
And...... I also doubled the default BUFFERPOOL, so if you leave everything the default then
BUFFERPOOL is now 52Mb instead of 26Mb, which should be ok for now.
===================================================================
RCS file: /home/cmunk/ircsystems/cvsroot/unreal/Changes,v
retrieving revision 1.1.1.1.2.1.2.1.2.179
diff -u -r1.1.1.1.2.1.2.1.2.179 Changes
--- Changes 2000/08/07 16:16:14 1.1.1.1.2.1.2.1.2.179
+++ Changes 2000/08/07 16:56:17
@@ -530,3 +530,4 @@
Config, and all the things we want them to read/do to compile the IRCd
- Updated PREFIX Client Protoctl
- Added ^MrMike^'s command list, this one will be updated
+- Removed ID_CVS, hopefully fixing some bastard stuff
Bram Matthys