Struct Session 

pub struct Session { /* private fields */ }

What one connection has chosen.

Implementations

impl Session

pub fn new(id: u64) -> Session

A new connection, on database zero with no name.

pub fn row(&self) -> &Arc<Client>

The row every other thread sees this connection through.

Handed to the server once, when the connection is accepted, so that CLIENT LIST can find it. A session nobody hands over is one no other thread can see, which is every embedded caller and every test.

pub fn opened(&mut self, now_ms: u64)

Say when this connection was opened, which is what age counts from.

Called by whoever opened it, which is the only place that knows. A session nobody tells has no age and reports zero, which is every embedded caller and every test.

pub fn set_socket(&mut self, peer: &str, local: &str, fd: i32, unix: bool)

Say what the socket under this connection is.

Called once, by whoever accepted it, which is the only place that knows. The two addresses are already in the spelling CLIENT INFO reports them in, because turning a socket address into that spelling is the job of the layer that has the socket.

pub fn read_bytes(&mut self, n: usize)

Note bytes that arrived, and that a read carried them.

pub fn wrote_bytes(&mut self, n: usize)

Note bytes that went out.

pub fn note_buffers( &mut self, waiting: usize, room: usize, held: usize, reply: usize, )

Note what the two buffers are holding, and which protocol they are in.

waiting is the framed bytes that have not been read yet, room is what is left in the read buffer after them, held is what the reply buffer still owes and reply is its capacity. The high water mark is kept here rather than by the caller so that the caller only has to say what is true now.

pub fn note_proto(&mut self, version: i64)

Note which protocol this connection is being answered in.

Written after each command rather than with the buffers, because HELLO changes it in the reply buffer and a connection that switched to RESP3 halfway through a pipeline should be listed as being on it.

pub fn finished(&mut self)

Note that the command running is over, and put what it changed about this connection where another thread can see it.

The count goes up here and not where the command name is noted, so that a connection asking CLIENT INFO is told how many commands it had sent before this one. That is what a real server answers: it counts in commandProcessed and that runs after the body.

The rest is the publishing. Which database a connection is in, what it is subscribed to, whether it is in a transaction and how many keys it is watching are all things a command can have just changed, and they are all things CLIENT LIST on another thread reports. Rather than hunting down every command that can move one of them, all six are written out here, which is six ordinary stores to a line this thread already owns.

pub const fn reply_mode(&self) -> Reply

What this connection has asked to hear back.

pub const fn step_reply(&mut self)

Step the skipping state on by one command.

Called after every command by whoever is deciding whether to keep the reply, so that SKIP covers exactly the one command after it.

pub const fn id(&self) -> u64

The connection id, which HELLO reports and CLIENT will.

pub const fn db(&self) -> usize

Which database this connection is working in.

pub fn name(&self) -> &[u8]

The name the client gave itself, empty if it gave none.

pub fn reset(&mut self)

Put everything back the way it was when the connection was opened.

The protocol is not here because it is not here: it lives in the reply buffer, and RESET sets it back there.