IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It can be useful for a irpc message to be one-way, where the client
sends a messages and the server does not reply. This will be used for
things like a triger message from an auth context to the drepl server
to tell it to try a REPL_SECRET on a user in a RODC.
Previously we've used raw messaging for messages that have no reply,
but that doesn't allow us to use messages described by IDL
Pair-Programmed-With: Andrew Bartlett <abartlet@samba.org>
2007-09-29 More higher-level passing around of lp_ctx.
2007-09-29 Fix warning.
2007-09-29 Pass loadparm contexts on a higher level.
2007-09-29 Avoid using global loadparm context.
(This used to be commit 3468952e771ab31f90b6c374ade01c5550810f42)
There are still a few tidyups of old FSF addresses to come (in both s3
and s4). More commits soon.
(This used to be commit fcf38a38ac691abd0fa51b89dc951a08e89fdafa)
uint32_t server_id
to
struct server_id server_id;
which allows a server ID to have an node number. The node number will
be zero in non-clustered case. This is the most basic hook needed for
clustering, and ctdb.
(This used to be commit 2365abaa991d57d68c6ebe9be608e01c907102eb)
will need a separate messaging endpoint per open file. To make this
efficient extend the messaging layer to have a new registration
function for temporary message types that maps via an idtree.
I have updated the LOCAL-MESSAGING test to use the new function.
(This used to be commit 4b976851d8b7ccd2c40010be095cef7fecf9e722)
we don't have a server messaging context. We should replace the
datagram messages with stream sockets in this case, so we don't have
to create a unique socket.
Andrew Bartlett
(This used to be commit fd974fb64792f8f6c532b01d2a2e012be18eef7e)
be able to send a message to the "ldap_server" task without having to
know its task ID.
(This used to be commit 8f69867867857e0c9a9246c2dec9612ccc234724)
compared to about 20k messages/sec for the raw messaging layer. I
think that is quite acceptable given the extra functionality.
(This used to be commit a05d38d1d91f1f54d3e3794a596b468992594852)
management system I proposed on samba-technical a couple of days
ago. Essentially it is a very lightweight way for any code in Samba to
make IDL based rpc calls to anywhere else in the code, without the
client or server having to go to the trouble of setting up a full rpc
service.
It can be used with any of our existing IDL, but I expect it will
mostly be used for a new set of Samba specific management calls.
The LOCAL-IRPC torture test demonstrates how it can be used by calling
the echo_AddOne() call over this transport.
(This used to be commit 3d589a09954eb8b318f567e1150b0c27412fb942)