nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 09:58:01 +00:00
Code Issues Projects Releases Wiki Activity
9396fcc9f7
putty-source/windows/winhsock.c

347 lines
9.7 KiB
C
Raw Normal View History

Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
/*
* General mechanism for wrapping up reading/writing of Windows
* HANDLEs into a PuTTY Socket abstraction.
*/
#include <stdio.h>
#include <assert.h>
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
#include <limits.h>
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
#include "tree234.h"
#include "putty.h"
#include "network.h"
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
typedef struct HandleSocket {
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
HANDLE send_H, recv_H, stderr_H;
struct handle *send_h, *recv_h, *stderr_h;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
/*
* Freezing one of these sockets is a slightly fiddly business,
* because the reads from the handle are happening in a separate
* thread as blocking system calls and so once one is in progress
* it can't sensibly be interrupted. Hence, after the user tries
* to freeze one of these sockets, it's unavoidable that we may
* receive one more load of data before we manage to get
* winhandl.c to stop reading.
*/
enum {
UNFROZEN, /* reading as normal */
FREEZING, /* have been set to frozen but winhandl is still reading */
FROZEN, /* really frozen - winhandl has been throttled */
THAWING /* we're gradually releasing our remaining data */
} frozen;
/* We buffer data here if we receive it from winhandl while frozen. */
bufchain inputdata;
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
/* Data received from stderr_H, if we have one. */
bufchain stderrdata;
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
int defer_close, deferred_close; /* in case of re-entrance */
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
char *error;
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Plug *plug;
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
Socket sock;
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
} HandleSocket;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
static int handle_gotdata(struct handle *h, void *data, int len)
{
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
HandleSocket *hs = (HandleSocket *)handle_get_privdata(h);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
if (len < 0) {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
plug_closing(hs->plug, "Read error from handle", 0, 0);
Don't treat plug_closing() and plug_receive() as returning backlog. plug_receive() and plug_closing() return 0 or 1 depending on whether they think the main connection has closed. It is not appropriate, as handle_gotdata and handle_socket_unfreeze did, to treat them as returning a backlog. In fact, plugs are unusual in PuTTY in not reporting a backlog, but just calling into the socket to freeze and unfreeze it as required.
2016-06-04 14:42:06 +00:00
return 0;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
} else if (len == 0) {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
plug_closing(hs->plug, NULL, 0, 0);
Don't treat plug_closing() and plug_receive() as returning backlog. plug_receive() and plug_closing() return 0 or 1 depending on whether they think the main connection has closed. It is not appropriate, as handle_gotdata and handle_socket_unfreeze did, to treat them as returning a backlog. In fact, plugs are unusual in PuTTY in not reporting a backlog, but just calling into the socket to freeze and unfreeze it as required.
2016-06-04 14:42:06 +00:00
return 0;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
} else {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
assert(hs->frozen != FROZEN && hs->frozen != THAWING);
if (hs->frozen == FREEZING) {
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
/*
* If we've received data while this socket is supposed to
* be frozen (because the read winhandl.c started before
* sk_set_frozen was called has now returned) then buffer
* the data for when we unfreeze.
*/
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
bufchain_add(&hs->inputdata, data, len);
hs->frozen = FROZEN;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
/*
* And return a very large backlog, to prevent further
* data arriving from winhandl until we unfreeze.
*/
return INT_MAX;
} else {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
plug_receive(hs->plug, 0, data, len);
Don't treat plug_closing() and plug_receive() as returning backlog. plug_receive() and plug_closing() return 0 or 1 depending on whether they think the main connection has closed. It is not appropriate, as handle_gotdata and handle_socket_unfreeze did, to treat them as returning a backlog. In fact, plugs are unusual in PuTTY in not reporting a backlog, but just calling into the socket to freeze and unfreeze it as required.
2016-06-04 14:42:06 +00:00
return 0;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
}
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
}
}
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
static int handle_stderr(struct handle *h, void *data, int len)
{
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
HandleSocket *hs = (HandleSocket *)handle_get_privdata(h);
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
if (len > 0)
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
log_proxy_stderr(hs->plug, &hs->stderrdata, data, len);
In GUI PuTTY, log standard error from local proxy commands. On both Unix and Windows, we now redirect the local proxy command's standard error into a third pipe; data received from that pipe is broken up at newlines and logged in the Event Log. So if the proxy command emits any error messages in the course of failing to connect to something, you now have a fighting chance of finding out what went wrong. This feature is disabled in command-line tools like PSFTP and Plink, on the basis that in that situation it seems more likely that the user would expect standard-error output to go to the ordinary standard error in the ordinary way. Only GUI PuTTY catches it and logs it like this, because it either doesn't have a standard error at all (on Windows) or is likely to be pointing it at some completely unhelpful session log file (under X).
2015-11-22 11:50:37 +00:00
return 0;
}
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
static void handle_sentdata(struct handle *h, int new_backlog)
{
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
HandleSocket *hs = (HandleSocket *)handle_get_privdata(h);
Windows handle sockets: fix error handling in sentdata(). In the sentdata callback function given to handle_output_new, the 'new_backlog' parameter can be negative, and if so, it represents a Windows error code and not a backlog size at all. handle_sentdata was not checking for this before passing it on to plug_sent.
2017-02-22 21:57:04 +00:00
if (new_backlog < 0) {
/* Special case: this is actually reporting an error writing
* to the underlying handle, and our input value is the error
* code itself, negated. */
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
plug_closing(hs->plug, win_strerror(-new_backlog), -new_backlog, 0);
Windows handle sockets: fix error handling in sentdata(). In the sentdata callback function given to handle_output_new, the 'new_backlog' parameter can be negative, and if so, it represents a Windows error code and not a backlog size at all. handle_sentdata was not checking for this before passing it on to plug_sent.
2017-02-22 21:57:04 +00:00
return;
}
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
plug_sent(hs->plug, new_backlog);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static Plug *sk_handle_plug(Socket *s, Plug *p)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
HandleSocket *hs = container_of(s, HandleSocket, sock);
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Plug *ret = hs->plug;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
if (p)
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
hs->plug = p;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
return ret;
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void sk_handle_close(Socket *s)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
HandleSocket *hs = container_of(s, HandleSocket, sock);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
if (hs->defer_close) {
hs->deferred_close = TRUE;
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
return;
}
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
handle_free(hs->send_h);
handle_free(hs->recv_h);
CloseHandle(hs->send_H);
if (hs->recv_H != hs->send_H)
CloseHandle(hs->recv_H);
bufchain_clear(&hs->inputdata);
bufchain_clear(&hs->stderrdata);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
sfree(hs);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static int sk_handle_write(Socket *s, const void *data, int len)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
HandleSocket *hs = container_of(s, HandleSocket, sock);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
return handle_write(hs->send_h, data, len);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static int sk_handle_write_oob(Socket *s, const void *data, int len)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
/*
* oob data is treated as inband; nasty, but nothing really
* better we can do
*/
return sk_handle_write(s, data, len);
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void sk_handle_write_eof(Socket *s)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
HandleSocket *hs = container_of(s, HandleSocket, sock);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
handle_write_eof(hs->send_h);
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void sk_handle_flush(Socket *s)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
/* HandleSocket *hs = container_of(s, HandleSocket, sock); */
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
/* do nothing */
}
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
static void handle_socket_unfreeze(void *hsv)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
HandleSocket *hs = (HandleSocket *)hsv;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
void *data;
Don't treat plug_closing() and plug_receive() as returning backlog. plug_receive() and plug_closing() return 0 or 1 depending on whether they think the main connection has closed. It is not appropriate, as handle_gotdata and handle_socket_unfreeze did, to treat them as returning a backlog. In fact, plugs are unusual in PuTTY in not reporting a backlog, but just calling into the socket to freeze and unfreeze it as required.
2016-06-04 14:42:06 +00:00
int len;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
/*
* If we've been put into a state other than THAWING since the
* last callback, then we're done.
*/
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
if (hs->frozen != THAWING)
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
return;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
/*
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
* Get some of the data we've buffered.
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
*/
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
bufchain_prefix(&hs->inputdata, &data, &len);
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
assert(len > 0);
/*
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
* Hand it off to the plug. Be careful of re-entrance - that might
* have the effect of trying to close this socket.
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
*/
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
hs->defer_close = TRUE;
plug_receive(hs->plug, 0, data, len);
bufchain_consume(&hs->inputdata, len);
hs->defer_close = FALSE;
if (hs->deferred_close) {
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
sk_handle_close(&hs->sock);
Implement deferred closing of Windows handle-sockets. When a handle socket is in THAWING state and handle_socket_unfreeze is gradually passing the backlogged data on to the plug, the plug might suddenly turn round and close the socket in the course of handling plug_receive(), which means that handle_socket_unfreeze had better be careful not to have had everything vanish out from under it when that call returns. To solve this, I've added a 'deferred close' flag which handle_socket_unfreeze can set around its call to plug_receive, and handle_socket_close will detect that and not actually free the socket, instead leaving that for handle_socket_unfreeze to do under its own control.
2017-02-16 20:26:58 +00:00
return;
}
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
if (bufchain_size(&hs->inputdata) > 0) {
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
/*
* If there's still data in our buffer, stay in THAWING state,
* and reschedule ourself.
*/
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
queue_toplevel_callback(handle_socket_unfreeze, hs);
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
} else {
/*
* Otherwise, we've successfully thawed!
*/
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
hs->frozen = UNFROZEN;
handle_unthrottle(hs->recv_h, 0);
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
}
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static void sk_handle_set_frozen(Socket *s, int is_frozen)
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
HandleSocket *hs = container_of(s, HandleSocket, sock);
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
if (is_frozen) {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
switch (hs->frozen) {
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
case FREEZING:
case FROZEN:
return; /* nothing to do */
case THAWING:
/*
* We were in the middle of emptying our bufchain, and got
* frozen again. In that case, winhandl.c is already
* throttled, so just return to FROZEN state. The toplevel
* callback will notice and disable itself.
*/
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
hs->frozen = FROZEN;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
break;
case UNFROZEN:
/*
* The normal case. Go to FREEZING, and expect one more
* load of data from winhandl if we're unlucky.
*/
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
hs->frozen = FREEZING;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
break;
}
} else {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
switch (hs->frozen) {
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
case UNFROZEN:
case THAWING:
return; /* nothing to do */
case FREEZING:
/*
* If winhandl didn't send us any data throughout the time
* we were frozen, then we'll still be in this state and
* can just unfreeze in the trivial way.
*/
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
assert(bufchain_size(&hs->inputdata) == 0);
hs->frozen = UNFROZEN;
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
break;
case FROZEN:
/*
* If we have buffered data, go to THAWING and start
* releasing it in top-level callbacks.
*/
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
hs->frozen = THAWING;
queue_toplevel_callback(handle_socket_unfreeze, hs);
Implement freezing on Windows handle sockets. That's been a FIXME in the code for ages, because it's difficult to get winhandl.c to stop an already-started read from a handle (since the read is a blocking system call running in a separate thread). But I now realise it isn't absolutely necessary to do so - you can just buffer one lot of data from winhandl and _then_ tell it to stop. [originally from svn r10067]
2013-11-17 14:03:48 +00:00
}
}
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static const char *sk_handle_socket_error(Socket *s)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
HandleSocket *hs = container_of(s, HandleSocket, sock);
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
return hs->error;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
}
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
static char *sk_handle_peer_info(Socket *s)
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
HandleSocket *hs = container_of(s, HandleSocket, sock);
Log the client process ID for Windows named pipes too. Turns out it didn't take much googling to find the right API function.
2015-05-18 15:00:13 +00:00
ULONG pid;
static HMODULE kernel32_module;
DECL_WINDOWS_FUNCTION(static, BOOL, GetNamedPipeClientProcessId,
(HANDLE, PULONG));
if (!kernel32_module) {
kernel32_module = load_system32_dll("kernel32.dll");
Coverity build fixes. Like every other toolchain I've tried, my Coverity scanning build has its share of random objections to parts of my Windows API type- checking system. I do wonder if that bright idea was worth the hassle - but it would probably cost all the annoyance all over again to back out now...
2017-06-20 18:02:48 +00:00
#if (defined _MSC_VER && _MSC_VER < 1900) || defined __MINGW32__ || defined COVERITY
Condition out some API type-checks in the MinGW build. A couple of the functions for which I was already turning off the type check for old Visual Studio turn out to also need it turning off for MinGW.
2017-04-15 17:13:47 +00:00
/* For older Visual Studio, and MinGW too (at least as of
* Ubuntu 16.04), this function isn't available in the header
Coverity build fixes. Like every other toolchain I've tried, my Coverity scanning build has its share of random objections to parts of my Windows API type- checking system. I do wonder if that bright idea was worth the hassle - but it would probably cost all the annoyance all over again to back out now...
2017-06-20 18:02:48 +00:00
* files to type-check. Ditto the toolchain I use for
* Coveritying the Windows code. */
Add automatic type-checking to GET_WINDOWS_FUNCTION. This gives me an extra safety-check against having mistyped one of the function prototypes that we load at run time from DLLs: we verify that the typedef we defined based on the prototype in our source code matches the type of the real function as declared in the Windows headers. This was an idea I had while adding a pile of further functions using this mechanism. It didn't catch any errors (either in the new functions or in the existing collection), but that's no reason not to keep it anyway now that I've thought of it! In VS2015, this automated type-check works for most functions, but a couple manage to break it. SetCurrentProcessExplicitAppUserModelID in winjump.c can't be type-checked, because including <shobjidl.h> where that function is declared would also bring in a load of other stuff that conflicts with the painful manual COM declarations in winjump.c. (That stuff could probably be removed now we're on an up-to-date Visual Studio, on the other hand, but that's a separate chore.) And gai_strerror, used in winnet.c, does _have_ an implementation in a DLL, but the header files like to provide an inline version with a different calling convention, which defeats this error-checking trick. And in the older VS2003 that we still precautionarily build with, several more type-checks have to be #ifdeffed out because the functions they check against just aren't there at all.
2017-04-11 17:56:55 +00:00
GET_WINDOWS_FUNCTION_NO_TYPECHECK(
kernel32_module, GetNamedPipeClientProcessId);
#else
GET_WINDOWS_FUNCTION(
kernel32_module, GetNamedPipeClientProcessId);
#endif
Log the client process ID for Windows named pipes too. Turns out it didn't take much googling to find the right API function.
2015-05-18 15:00:13 +00:00
}
/*
* Of course, not all handles managed by this module will be
* server ends of named pipes, but if they are, then it's useful
* to log what we can find out about the client end.
*/
if (p_GetNamedPipeClientProcessId &&
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
p_GetNamedPipeClientProcessId(hs->send_H, &pid))
Log the client process ID for Windows named pipes too. Turns out it didn't take much googling to find the right API function.
2015-05-18 15:00:13 +00:00
return dupprintf("process id %lu", (unsigned long)pid);
Log identifying information for the other end of connections. When anyone connects to a PuTTY tool's listening socket - whether it's a user of a local->remote port forwarding, a connection-sharing downstream or a client of Pageant - we'd like to log as much information as we can find out about where the connection came from. To that end, I've implemented a function sk_peer_info() in the socket abstraction, which returns a freeform text string as best it can (or NULL, if it can't get anything at all) describing the thing at the other end of the connection. For TCP connections, this is done using getpeername() to get an IP address and port in the obvious way; for Unix-domain sockets, we attempt SO_PEERCRED (conditionalised on some moderately hairy autoconfery) to get the pid and owner of the peer. I haven't implemented anything for Windows named pipes, but I will if I hear of anything useful.
2015-05-18 12:57:45 +00:00
return NULL;
}
Name vtable structure types more consistently. Now they're all called FooVtable, instead of a mixture of that and Foo_vtable.
2018-10-05 06:03:46 +00:00
static const SocketVtable HandleSocket_sockvt = {
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
sk_handle_plug,
sk_handle_close,
sk_handle_write,
sk_handle_write_oob,
sk_handle_write_eof,
sk_handle_flush,
sk_handle_set_frozen,
sk_handle_socket_error,
sk_handle_peer_info,
};
Get rid of lots of implicit pointer types. All the main backend structures - Ssh, Telnet, Pty, Serial etc - now describe structure types themselves rather than pointers to them. The same goes for the codebase-wide trait types Socket and Plug, and the supporting types SockAddr and Pinger. All those things that were typedefed as pointers are older types; the newer ones have the explicit * at the point of use, because that's what I now seem to be preferring. But whichever one of those is better, inconsistently using a mixture of the two styles is worse, so let's make everything consistent. A few types are still implicitly pointers, such as Bignum and some of the GSSAPI types; generally this is either because they have to be void *, or because they're typedefed differently on different platforms and aren't always pointers at all. Can't be helped. But I've got rid of the main ones, at least.
2018-10-04 18:10:23 +00:00
Socket *make_handle_socket(HANDLE send_H, HANDLE recv_H, HANDLE stderr_H,
Plug *plug, int overlapped)
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
{
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
HandleSocket *hs;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
int flags = (overlapped ? HANDLE_FLAG_OVERLAPPED : 0);
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
hs = snew(HandleSocket);
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
hs->sock.vt = &HandleSocket_sockvt;
Modernise the Socket/Plug vtable system. Now I've got FROMFIELD, I can rework it so that structures providing an implementation of the Socket or Plug trait no longer have to have the vtable pointer as the very first thing in the structure. In particular, this means that the ProxySocket structure can now directly implement _both_ the Socket and Plug traits, which is always _logically_ how it's worked, but previously it had to be implemented via two separate structs linked to each other.
2018-05-27 08:29:33 +00:00
hs->plug = plug;
hs->error = NULL;
hs->frozen = UNFROZEN;
bufchain_init(&hs->inputdata);
bufchain_init(&hs->stderrdata);
hs->recv_H = recv_H;
hs->recv_h = handle_input_new(hs->recv_H, handle_gotdata, hs, flags);
hs->send_H = send_H;
hs->send_h = handle_output_new(hs->send_H, handle_sentdata, hs, flags);
hs->stderr_H = stderr_H;
if (hs->stderr_H)
hs->stderr_h = handle_input_new(hs->stderr_H, handle_stderr,
hs, flags);
hs->defer_close = hs->deferred_close = FALSE;
Make Socket and Plug into structs. I think that means that _every_ one of my traitoids is now a struct containing a vtable pointer as one of its fields (albeit sometimes the only field), and never just a bare pointer.
2018-10-05 06:24:16 +00:00
return &hs->sock;
Factor out the HANDLE-to-Socket adapter from winproxy.c. It's now kept in a separate module, where it can be reused conveniently for other kinds of Windows HANDLE that I want to wrap in the PuTTY Socket abstraction - for example, the named pipes that I shortly plan to use for the Windows side of connection-sharing IPC. [originally from svn r10066]
2013-11-17 14:03:44 +00:00
}
Reference in New Issue Copy Permalink