nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
445030b3ea
putty-source/sshchan.h

212 lines
8.9 KiB
C
Raw Normal View History

Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
/*
* Abstraction of the various ways to handle the local end of an SSH
* connection-layer channel.
*/
#ifndef PUTTY_SSHCHAN_H
#define PUTTY_SSHCHAN_H
struct ChannelVtable {
void (*free)(Channel *);
/* Called for channel types that were created at the same time as
* we sent an outgoing CHANNEL_OPEN, when the confirmation comes
* back from the server indicating that the channel has been
* opened, or the failure message indicating that it hasn't,
* respectively. In the latter case, this must _not_ free the
* Channel structure - the client will call the free method
* separately. But it might do logging or other local cleanup. */
void (*open_confirmation)(Channel *);
void (*open_failed)(Channel *, const char *error_text);
int (*send)(Channel *, int is_stderr, const void *buf, int len);
void (*send_eof)(Channel *);
void (*set_input_wanted)(Channel *, int wanted);
char *(*log_close_msg)(Channel *);
int (*want_close)(Channel *, int sent_local_eof, int rcvd_remote_eof);
Devolve channel-request handling to Channel vtable. Instead of the central code in ssh2_connection_filter_queue doing both the job of parsing the channel request and deciding whether it's acceptable, each Channel vtable now has a method for every channel request type we recognise.
2018-09-26 16:34:20 +00:00
/* A method for every channel request we know of. All of these
* return TRUE for success or FALSE for failure. */
int (*rcvd_exit_status)(Channel *, int status);
int (*rcvd_exit_signal)(
Channel *chan, ptrlen signame, int core_dumped, ptrlen msg);
int (*rcvd_exit_signal_numeric)(
Channel *chan, int signum, int core_dumped, ptrlen msg);
Move channel-opening logic out into subroutines. Each of the new subroutines corresponds to one of the channel types for which we know how to parse a CHANNEL_OPEN, and has a collection of parameters corresponding to the fields of that message structure. ssh2_connection_filter_queue now confines itself to parsing the message, calling one of those functions, and constructing an appropriate reply message if any.
2018-09-26 17:02:33 +00:00
/* A method for signalling success/failure responses to channel
* requests initiated from the SshChannel vtable with want_reply
* true. */
void (*request_response)(Channel *, int success);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
};
struct Channel {
const struct ChannelVtable *vt;
unsigned initial_fixed_window_size;
};
#define chan_free(ch) ((ch)->vt->free(ch))
#define chan_open_confirmation(ch) ((ch)->vt->open_confirmation(ch))
#define chan_open_failed(ch, err) ((ch)->vt->open_failed(ch, err))
#define chan_send(ch, err, buf, len) ((ch)->vt->send(ch, err, buf, len))
#define chan_send_eof(ch) ((ch)->vt->send_eof(ch))
#define chan_set_input_wanted(ch, wanted) \
((ch)->vt->set_input_wanted(ch, wanted))
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 12:47:13 +00:00
#define chan_log_close_msg(ch) ((ch)->vt->log_close_msg(ch))
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
#define chan_want_close(ch, leof, reof) ((ch)->vt->want_close(ch, leof, reof))
Devolve channel-request handling to Channel vtable. Instead of the central code in ssh2_connection_filter_queue doing both the job of parsing the channel request and deciding whether it's acceptable, each Channel vtable now has a method for every channel request type we recognise.
2018-09-26 16:34:20 +00:00
#define chan_rcvd_exit_status(ch, status) \
((ch)->vt->rcvd_exit_status(ch, status))
#define chan_rcvd_exit_signal(ch, sig, core, msg) \
((ch)->vt->rcvd_exit_signal(ch, sig, core, msg))
#define chan_rcvd_exit_signal_numeric(ch, sig, core, msg) \
((ch)->vt->rcvd_exit_signal_numeric(ch, sig, core, msg))
Move channel-opening logic out into subroutines. Each of the new subroutines corresponds to one of the channel types for which we know how to parse a CHANNEL_OPEN, and has a collection of parameters corresponding to the fields of that message structure. ssh2_connection_filter_queue now confines itself to parsing the message, calling one of those functions, and constructing an appropriate reply message if any.
2018-09-26 17:02:33 +00:00
#define chan_request_response(ch, success) \
((ch)->vt->request_response(ch, success))
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
/*
* Reusable methods you can put in vtables to give default handling of
* some of those functions.
*/
/* open_confirmation / open_failed for any channel it doesn't apply to */
void chan_remotely_opened_confirmation(Channel *chan);
void chan_remotely_opened_failure(Channel *chan, const char *errtext);
/* want_close for any channel that wants the default behaviour of not
* closing until both directions have had an EOF */
Allow channels not to close immediately after two EOFs. Some kinds of channel, even after they've sent EOF in both directions, still have something to do before they initiate the CLOSE mechanism and wind up the channel completely. For example, a session channel with a subprocess running inside it will want to be sure to send the "exit-status" or "exit-signal" notification, even if that happens after bidirectional EOF of the data channels. Previously, the SSH-2 connection layer had the standard policy that once EOF had been both sent and received, it would start the final close procedure. There's a method chan_want_close() by which a Channel could vary this policy in one direction, by indicating that it wanted the close procedure to commence after EOF was sent in only one direction. Its parameters are a pair of booleans saying whether EOF has been sent, and whether it's been received. Now chan_want_close can vary the policy in the other direction as well: if it returns FALSE even when _both_ parameters are true, the connection layer will honour that, and not send CHANNEL_CLOSE. If it does that, the Channel is responsible for indicating when it _does_ want close later, by calling sshfwd_initiate_close.
2018-10-18 17:02:59 +00:00
int chan_default_want_close(Channel *, int, int);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
Devolve channel-request handling to Channel vtable. Instead of the central code in ssh2_connection_filter_queue doing both the job of parsing the channel request and deciding whether it's acceptable, each Channel vtable now has a method for every channel request type we recognise.
2018-09-26 16:34:20 +00:00
/* default implementations that refuse all the channel requests */
int chan_no_exit_status(Channel *, int);
int chan_no_exit_signal(Channel *, ptrlen, int, ptrlen);
int chan_no_exit_signal_numeric(Channel *, int, int, ptrlen);
Move channel-opening logic out into subroutines. Each of the new subroutines corresponds to one of the channel types for which we know how to parse a CHANNEL_OPEN, and has a collection of parameters corresponding to the fields of that message structure. ssh2_connection_filter_queue now confines itself to parsing the message, calling one of those functions, and constructing an appropriate reply message if any.
2018-09-26 17:02:33 +00:00
/* default implementation that never expects to receive a response */
void chan_no_request_response(Channel *, int);
Move the zombiechan implementation into sshcommon.c. It doesn't really have to be in ssh.c sharing that file's internal data structures; it's as much an independent object implementation as any of the less trivial Channel instances. So it's another thing we can get out of that too-large source file.
2018-09-19 19:31:19 +00:00
/*
* Constructor for a trivial do-nothing implementation of
* ChannelVtable. Used for 'zombie' channels, i.e. channels whose
* proper local source of data has been shut down or otherwise stopped
* existing, but the SSH side is still there and needs some kind of a
* Channel implementation to talk to. In particular, the want_close
* method for this channel always returns 'yes, please close this
* channel asap', regardless of whether local and/or remote EOF have
* been sent - indeed, even if _neither_ has.
*/
Channel *zombiechan_new(void);
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 12:47:13 +00:00
/* ----------------------------------------------------------------------
* This structure is owned by an SSH connection layer, and identifies
* the connection layer's end of the channel, for the Channel
* implementation to talk back to.
*/
struct SshChannelVtable {
Server prep: support stderr output on channels. The vtable method underneath sshfwd_write now takes an is_stderr parameter, and in SSH-2, this is implemented by having separate stdout and stderr bufchains in each outgoing channel, and counting the size of both for the purposes of measuring backlog and so forth. To avoid making _most_ call sites more verbose, the usual macro wrapper hasn't changed its API; it just sets is_stderr=FALSE. To use the new feature, there's an sshfwd_write_ext macro that exposes the extra parameter.
2018-10-20 20:41:28 +00:00
int (*write)(SshChannel *c, int is_stderr, const void *, int);
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 12:47:13 +00:00
void (*write_eof)(SshChannel *c);
Rename sshfwd_unclean_close to sshfwd_initiate_close. Turns out that initiation of a CHANNEL_CLOSE message before both sides have sent EOF is not only for _unclean_ closures or emergencies; it's actually a perfectly normal thing that some channel types want to do. (For example, a channel with a pty at the server end of it has no real concept of sending EOF independently in both directions: when the pty master sends EIO, the pty is no longer functioning, and you can no longer send to it any more than you can receive.)
2018-10-13 09:30:03 +00:00
void (*initiate_close)(SshChannel *c, const char *err);
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 12:47:13 +00:00
void (*unthrottle)(SshChannel *c, int bufsize);
Conf *(*get_conf)(SshChannel *c);
void (*window_override_removed)(SshChannel *c);
void (*x11_sharing_handover)(SshChannel *c,
ssh_sharing_connstate *share_cs,
share_channel *share_chan,
const char *peer_addr, int peer_port,
int endian, int protomajor, int protominor,
const void *initial_data, int initial_len);
Move channel-opening logic out into subroutines. Each of the new subroutines corresponds to one of the channel types for which we know how to parse a CHANNEL_OPEN, and has a collection of parameters corresponding to the fields of that message structure. ssh2_connection_filter_queue now confines itself to parsing the message, calling one of those functions, and constructing an appropriate reply message if any.
2018-09-26 17:02:33 +00:00
/*
* All the outgoing channel requests we support. Each one has a
* want_reply flag, which will cause a callback to
* chan_request_response when the result is available.
*
* The ones that return 'int' use it to indicate that the SSH
* protocol in use doesn't support this request at all.
*
* (It's also intentional that not all of them have a want_reply
* flag: the ones that don't are because SSH-1 has no method for
* signalling success or failure of that request, or because we
* wouldn't do anything usefully different with the reply in any
* case.)
*/
void (*request_x11_forwarding)(
SshChannel *c, int want_reply, const char *authproto,
const char *authdata, int screen_number, int oneshot);
void (*request_agent_forwarding)(
SshChannel *c, int want_reply);
void (*request_pty)(
SshChannel *c, int want_reply, Conf *conf, int w, int h);
int (*send_env_var)(
SshChannel *c, int want_reply, const char *var, const char *value);
void (*start_shell)(
SshChannel *c, int want_reply);
void (*start_command)(
SshChannel *c, int want_reply, const char *command);
int (*start_subsystem)(
SshChannel *c, int want_reply, const char *subsystem);
int (*send_serial_break)(
SshChannel *c, int want_reply, int length); /* length=0 for default */
int (*send_signal)(
SshChannel *c, int want_reply, const char *signame);
void (*send_terminal_size_change)(
SshChannel *c, int w, int h);
void (*hint_channel_is_simple)(SshChannel *c);
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 12:47:13 +00:00
};
struct SshChannel {
const struct SshChannelVtable *vt;
Give SshChannel a pointer to its owning ConnectionLayer. In my future plans, some SshChannels are going to need to be able to ask favours from the connection layer as a whole. And an SshChannel is inextricably tied to an instance of the connection layer, so there's no real reason _not_ to make the pointer generally available.
2018-10-14 16:17:48 +00:00
ConnectionLayer *cl;
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 12:47:13 +00:00
};
Server prep: support stderr output on channels. The vtable method underneath sshfwd_write now takes an is_stderr parameter, and in SSH-2, this is implemented by having separate stdout and stderr bufchains in each outgoing channel, and counting the size of both for the purposes of measuring backlog and so forth. To avoid making _most_ call sites more verbose, the usual macro wrapper hasn't changed its API; it just sets is_stderr=FALSE. To use the new feature, there's an sshfwd_write_ext macro that exposes the extra parameter.
2018-10-20 20:41:28 +00:00
#define sshfwd_write(c, buf, len) ((c)->vt->write(c, FALSE, buf, len))
#define sshfwd_write_ext(c, stderr, buf, len) \
((c)->vt->write(c, stderr, buf, len))
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 12:47:13 +00:00
#define sshfwd_write_eof(c) ((c)->vt->write_eof(c))
Rename sshfwd_unclean_close to sshfwd_initiate_close. Turns out that initiation of a CHANNEL_CLOSE message before both sides have sent EOF is not only for _unclean_ closures or emergencies; it's actually a perfectly normal thing that some channel types want to do. (For example, a channel with a pty at the server end of it has no real concept of sending EOF independently in both directions: when the pty master sends EIO, the pty is no longer functioning, and you can no longer send to it any more than you can receive.)
2018-10-13 09:30:03 +00:00
#define sshfwd_initiate_close(c, err) ((c)->vt->initiate_close(c, err))
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 12:47:13 +00:00
#define sshfwd_unthrottle(c, bufsize) ((c)->vt->unthrottle(c, bufsize))
#define sshfwd_get_conf(c) ((c)->vt->get_conf(c))
#define sshfwd_window_override_removed(c) ((c)->vt->window_override_removed(c))
#define sshfwd_x11_sharing_handover(c, cs, ch, pa, pp, e, pmaj, pmin, d, l) \
((c)->vt->x11_sharing_handover(c, cs, ch, pa, pp, e, pmaj, pmin, d, l))
Move channel-opening logic out into subroutines. Each of the new subroutines corresponds to one of the channel types for which we know how to parse a CHANNEL_OPEN, and has a collection of parameters corresponding to the fields of that message structure. ssh2_connection_filter_queue now confines itself to parsing the message, calling one of those functions, and constructing an appropriate reply message if any.
2018-09-26 17:02:33 +00:00
#define sshfwd_request_x11_forwarding(c, wr, ap, ad, scr, oneshot) \
((c)->vt->request_x11_forwarding(c, wr, ap, ad, scr, oneshot))
#define sshfwd_request_agent_forwarding(c, wr) \
((c)->vt->request_agent_forwarding(c, wr))
#define sshfwd_request_pty(c, wr, conf, w, h) \
((c)->vt->request_pty(c, wr, conf, w, h))
#define sshfwd_send_env_var(c, wr, var, value) \
((c)->vt->send_env_var(c, wr, var, value))
#define sshfwd_start_shell(c, wr) \
((c)->vt->start_shell(c, wr))
#define sshfwd_start_command(c, wr, cmd) \
((c)->vt->start_command(c, wr, cmd))
#define sshfwd_start_subsystem(c, wr, subsys) \
((c)->vt->start_subsystem(c, wr, subsys))
#define sshfwd_send_serial_break(c, wr, length) \
((c)->vt->send_serial_break(c, wr, length))
#define sshfwd_send_signal(c, wr, sig) \
((c)->vt->send_signal(c, wr, sig))
#define sshfwd_send_terminal_size_change(c, w, h) \
((c)->vt->send_terminal_size_change(c, w, h))
#define sshfwd_hint_channel_is_simple(c) \
((c)->vt->hint_channel_is_simple(c))
Put a layer of abstraction in front of struct ssh_channel. Clients outside ssh.c - all implementations of Channel - will now not see the ssh_channel data type itself, but only a subobject of the interface type SshChannel. All the sshfwd_* functions have become methods in that interface type's vtable (though, wrapped in the usual kind of macros, the call sites look identical). This paves the way for me to split up the SSH-1 and SSH-2 connection layers and have each one lay out its channel bookkeeping structure as it sees fit; as long as they each provide an implementation of the sshfwd_ method family, the types behind that need not look different. A minor good effect of this is that the sshfwd_ methods are no longer global symbols, so they don't have to be stubbed in Unix Pageant to get it to compile.
2018-09-14 12:47:13 +00:00
Move mainchan into its own file, like agentf. This gets another big pile of logic out of ssh2connection and puts it somewhere more central. Now the only thing left in ssh2connection is the formatting and parsing of the various channel requests; the logic deciding which ones to issue and what to do about them is devolved to the Channel implementation, as it properly should be.
2018-09-30 06:16:38 +00:00
/* ----------------------------------------------------------------------
* The 'main' or primary channel of the SSH connection is special,
* because it's the one that's connected directly to parts of the
* frontend such as the terminal and the specials menu. So it exposes
* a richer API.
*/
mainchan *mainchan_new(
PacketProtocolLayer *ppl, ConnectionLayer *cl, Conf *conf,
int term_width, int term_height, int is_simple, SshChannel **sc_out);
void mainchan_get_specials(
mainchan *mc, add_special_fn_t add_special, void *ctx);
void mainchan_special_cmd(mainchan *mc, SessionSpecialCode code, int arg);
void mainchan_terminal_size(mainchan *mc, int width, int height);
Replace enum+union of local channel types with a vtable. There's now an interface called 'Channel', which handles the local side of an SSH connection-layer channel, in terms of knowing where to send incoming channel data to, whether to close the channel, etc. Channel and the previous 'struct ssh_channel' mutually refer. The latter contains all the SSH-specific parts, and as much of the common logic as possible: in particular, Channel doesn't have to know anything about SSH packet formats, or which SSH protocol version is in use, or deal with all the fiddly stuff about window sizes - with the exception that x11fwd.c's implementation of it does have to be able to ask for a small fixed initial window size for the bodgy system that distinguishes upstream from downstream X forwardings. I've taken the opportunity to move the code implementing the detailed behaviour of agent forwarding out of ssh.c, now that all of it is on the far side of a uniform interface. (This also means that if I later implement agent forwarding directly to a Unix socket as an alternative, it'll be a matter of changing just the one call to agentf_new() that makes the Channel to plug into a forwarding.)
2018-09-12 14:03:47 +00:00
#endif /* PUTTY_SSHCHAN_H */
Reference in New Issue Copy Permalink