ladybird/Libraries/LibIPC/TransportSocketWindows.h

59 lines
1.5 KiB
C
Raw Normal View History

LibIPC: Port to Windows The Linux IPC uses SCM_RIGHTS to transfer fds to another process (see TransportSocket::transfer, which calls LocalSocket::send_message). File descriptors are handled separately from regular data. On Windows handles are embedded in regular data. They are duplicated in the sender process. Socket handles need special code both on sender side (because they require using WSADuplicateSocket instead of DuplicateHandle, see TransportSocketWindows::duplicate_handles) and on receiver side (because they require WSASocket, see FileWindows.cpp). TransportSocketWindows::ReadResult::fds vector is always empty, it is kept the same as Linux version to avoid OS #ifdefs in Connection.h/.cpp and Web::HTML::MessagePort::read_from_transport. Separate handling of fds permeates all IPC code, it doesn't make sense to #ifdef out all this code on Windows. In other words, the Linux code is more generic - it handles both regular data and fds. On Windows, we need only the regular data portion of it, and we just use that. Duplicating handles on Windows requires pid of target (receiver) process (see TransportSocketWindows::m_peer_pid). This pid is received during special TransportSocketWindows initialization, which is performed only on Windows. It is handled in a separate PR #3179. Note: ChatGPT and [stackoverflow](https://stackoverflow.com/questions/25429887/getting-pid-of-peer-socket-on-windows) suggest using GetExtendedTcpTable/GetTcpTable2 to get peer pid, but this doesn't work because [MIB_TCPROW2::dwOwningPid](https://learn.microsoft.com/en-us/windows/win32/api/tcpmib/ns-tcpmib-mib_tcprow2) is "The PID of the process that issued a context bind for this TCP connection.", so for both ends it will return the pid of the process that called socketpair. Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
2025-01-31 10:57:34 +05:00
/*
* Copyright (c) 2024, Andrew Kaster <andrew@ladybird.org>
* Copyright (c) 2025, stasoid <stasoid@yahoo.com>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Queue.h>
LibIPC: Port to Windows The Linux IPC uses SCM_RIGHTS to transfer fds to another process (see TransportSocket::transfer, which calls LocalSocket::send_message). File descriptors are handled separately from regular data. On Windows handles are embedded in regular data. They are duplicated in the sender process. Socket handles need special code both on sender side (because they require using WSADuplicateSocket instead of DuplicateHandle, see TransportSocketWindows::duplicate_handles) and on receiver side (because they require WSASocket, see FileWindows.cpp). TransportSocketWindows::ReadResult::fds vector is always empty, it is kept the same as Linux version to avoid OS #ifdefs in Connection.h/.cpp and Web::HTML::MessagePort::read_from_transport. Separate handling of fds permeates all IPC code, it doesn't make sense to #ifdef out all this code on Windows. In other words, the Linux code is more generic - it handles both regular data and fds. On Windows, we need only the regular data portion of it, and we just use that. Duplicating handles on Windows requires pid of target (receiver) process (see TransportSocketWindows::m_peer_pid). This pid is received during special TransportSocketWindows initialization, which is performed only on Windows. It is handled in a separate PR #3179. Note: ChatGPT and [stackoverflow](https://stackoverflow.com/questions/25429887/getting-pid-of-peer-socket-on-windows) suggest using GetExtendedTcpTable/GetTcpTable2 to get peer pid, but this doesn't work because [MIB_TCPROW2::dwOwningPid](https://learn.microsoft.com/en-us/windows/win32/api/tcpmib/ns-tcpmib-mib_tcprow2) is "The PID of the process that issued a context bind for this TCP connection.", so for both ends it will return the pid of the process that called socketpair. Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
2025-01-31 10:57:34 +05:00
#include <LibCore/Socket.h>
#include <LibIPC/File.h>
namespace IPC {
class TransportSocketWindows {
AK_MAKE_NONCOPYABLE(TransportSocketWindows);
AK_MAKE_DEFAULT_MOVABLE(TransportSocketWindows);
public:
explicit TransportSocketWindows(NonnullOwnPtr<Core::LocalSocket> socket);
void set_peer_pid(int pid);
void set_up_read_hook(Function<void()>);
bool is_open() const;
void close();
2025-06-27 22:14:03 -07:00
void close_after_sending_all_pending_messages();
LibIPC: Port to Windows The Linux IPC uses SCM_RIGHTS to transfer fds to another process (see TransportSocket::transfer, which calls LocalSocket::send_message). File descriptors are handled separately from regular data. On Windows handles are embedded in regular data. They are duplicated in the sender process. Socket handles need special code both on sender side (because they require using WSADuplicateSocket instead of DuplicateHandle, see TransportSocketWindows::duplicate_handles) and on receiver side (because they require WSASocket, see FileWindows.cpp). TransportSocketWindows::ReadResult::fds vector is always empty, it is kept the same as Linux version to avoid OS #ifdefs in Connection.h/.cpp and Web::HTML::MessagePort::read_from_transport. Separate handling of fds permeates all IPC code, it doesn't make sense to #ifdef out all this code on Windows. In other words, the Linux code is more generic - it handles both regular data and fds. On Windows, we need only the regular data portion of it, and we just use that. Duplicating handles on Windows requires pid of target (receiver) process (see TransportSocketWindows::m_peer_pid). This pid is received during special TransportSocketWindows initialization, which is performed only on Windows. It is handled in a separate PR #3179. Note: ChatGPT and [stackoverflow](https://stackoverflow.com/questions/25429887/getting-pid-of-peer-socket-on-windows) suggest using GetExtendedTcpTable/GetTcpTable2 to get peer pid, but this doesn't work because [MIB_TCPROW2::dwOwningPid](https://learn.microsoft.com/en-us/windows/win32/api/tcpmib/ns-tcpmib-mib_tcprow2) is "The PID of the process that issued a context bind for this TCP connection.", so for both ends it will return the pid of the process that called socketpair. Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
2025-01-31 10:57:34 +05:00
void wait_until_readable();
ErrorOr<void> transfer_message(ReadonlyBytes, Vector<size_t> const& handle_offsets);
LibIPC: Port to Windows The Linux IPC uses SCM_RIGHTS to transfer fds to another process (see TransportSocket::transfer, which calls LocalSocket::send_message). File descriptors are handled separately from regular data. On Windows handles are embedded in regular data. They are duplicated in the sender process. Socket handles need special code both on sender side (because they require using WSADuplicateSocket instead of DuplicateHandle, see TransportSocketWindows::duplicate_handles) and on receiver side (because they require WSASocket, see FileWindows.cpp). TransportSocketWindows::ReadResult::fds vector is always empty, it is kept the same as Linux version to avoid OS #ifdefs in Connection.h/.cpp and Web::HTML::MessagePort::read_from_transport. Separate handling of fds permeates all IPC code, it doesn't make sense to #ifdef out all this code on Windows. In other words, the Linux code is more generic - it handles both regular data and fds. On Windows, we need only the regular data portion of it, and we just use that. Duplicating handles on Windows requires pid of target (receiver) process (see TransportSocketWindows::m_peer_pid). This pid is received during special TransportSocketWindows initialization, which is performed only on Windows. It is handled in a separate PR #3179. Note: ChatGPT and [stackoverflow](https://stackoverflow.com/questions/25429887/getting-pid-of-peer-socket-on-windows) suggest using GetExtendedTcpTable/GetTcpTable2 to get peer pid, but this doesn't work because [MIB_TCPROW2::dwOwningPid](https://learn.microsoft.com/en-us/windows/win32/api/tcpmib/ns-tcpmib-mib_tcprow2) is "The PID of the process that issued a context bind for this TCP connection.", so for both ends it will return the pid of the process that called socketpair. Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
2025-01-31 10:57:34 +05:00
enum class ShouldShutdown {
No,
Yes,
};
struct Message {
LibIPC: Port to Windows The Linux IPC uses SCM_RIGHTS to transfer fds to another process (see TransportSocket::transfer, which calls LocalSocket::send_message). File descriptors are handled separately from regular data. On Windows handles are embedded in regular data. They are duplicated in the sender process. Socket handles need special code both on sender side (because they require using WSADuplicateSocket instead of DuplicateHandle, see TransportSocketWindows::duplicate_handles) and on receiver side (because they require WSASocket, see FileWindows.cpp). TransportSocketWindows::ReadResult::fds vector is always empty, it is kept the same as Linux version to avoid OS #ifdefs in Connection.h/.cpp and Web::HTML::MessagePort::read_from_transport. Separate handling of fds permeates all IPC code, it doesn't make sense to #ifdef out all this code on Windows. In other words, the Linux code is more generic - it handles both regular data and fds. On Windows, we need only the regular data portion of it, and we just use that. Duplicating handles on Windows requires pid of target (receiver) process (see TransportSocketWindows::m_peer_pid). This pid is received during special TransportSocketWindows initialization, which is performed only on Windows. It is handled in a separate PR #3179. Note: ChatGPT and [stackoverflow](https://stackoverflow.com/questions/25429887/getting-pid-of-peer-socket-on-windows) suggest using GetExtendedTcpTable/GetTcpTable2 to get peer pid, but this doesn't work because [MIB_TCPROW2::dwOwningPid](https://learn.microsoft.com/en-us/windows/win32/api/tcpmib/ns-tcpmib-mib_tcprow2) is "The PID of the process that issued a context bind for this TCP connection.", so for both ends it will return the pid of the process that called socketpair. Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
2025-01-31 10:57:34 +05:00
Vector<u8> bytes;
Queue<File> fds; // always empty, present to avoid OS #ifdefs in Connection.cpp
LibIPC: Port to Windows The Linux IPC uses SCM_RIGHTS to transfer fds to another process (see TransportSocket::transfer, which calls LocalSocket::send_message). File descriptors are handled separately from regular data. On Windows handles are embedded in regular data. They are duplicated in the sender process. Socket handles need special code both on sender side (because they require using WSADuplicateSocket instead of DuplicateHandle, see TransportSocketWindows::duplicate_handles) and on receiver side (because they require WSASocket, see FileWindows.cpp). TransportSocketWindows::ReadResult::fds vector is always empty, it is kept the same as Linux version to avoid OS #ifdefs in Connection.h/.cpp and Web::HTML::MessagePort::read_from_transport. Separate handling of fds permeates all IPC code, it doesn't make sense to #ifdef out all this code on Windows. In other words, the Linux code is more generic - it handles both regular data and fds. On Windows, we need only the regular data portion of it, and we just use that. Duplicating handles on Windows requires pid of target (receiver) process (see TransportSocketWindows::m_peer_pid). This pid is received during special TransportSocketWindows initialization, which is performed only on Windows. It is handled in a separate PR #3179. Note: ChatGPT and [stackoverflow](https://stackoverflow.com/questions/25429887/getting-pid-of-peer-socket-on-windows) suggest using GetExtendedTcpTable/GetTcpTable2 to get peer pid, but this doesn't work because [MIB_TCPROW2::dwOwningPid](https://learn.microsoft.com/en-us/windows/win32/api/tcpmib/ns-tcpmib-mib_tcprow2) is "The PID of the process that issued a context bind for this TCP connection.", so for both ends it will return the pid of the process that called socketpair. Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
2025-01-31 10:57:34 +05:00
};
ShouldShutdown read_as_many_messages_as_possible_without_blocking(Function<void(Message&&)>&&);
LibIPC: Port to Windows The Linux IPC uses SCM_RIGHTS to transfer fds to another process (see TransportSocket::transfer, which calls LocalSocket::send_message). File descriptors are handled separately from regular data. On Windows handles are embedded in regular data. They are duplicated in the sender process. Socket handles need special code both on sender side (because they require using WSADuplicateSocket instead of DuplicateHandle, see TransportSocketWindows::duplicate_handles) and on receiver side (because they require WSASocket, see FileWindows.cpp). TransportSocketWindows::ReadResult::fds vector is always empty, it is kept the same as Linux version to avoid OS #ifdefs in Connection.h/.cpp and Web::HTML::MessagePort::read_from_transport. Separate handling of fds permeates all IPC code, it doesn't make sense to #ifdef out all this code on Windows. In other words, the Linux code is more generic - it handles both regular data and fds. On Windows, we need only the regular data portion of it, and we just use that. Duplicating handles on Windows requires pid of target (receiver) process (see TransportSocketWindows::m_peer_pid). This pid is received during special TransportSocketWindows initialization, which is performed only on Windows. It is handled in a separate PR #3179. Note: ChatGPT and [stackoverflow](https://stackoverflow.com/questions/25429887/getting-pid-of-peer-socket-on-windows) suggest using GetExtendedTcpTable/GetTcpTable2 to get peer pid, but this doesn't work because [MIB_TCPROW2::dwOwningPid](https://learn.microsoft.com/en-us/windows/win32/api/tcpmib/ns-tcpmib-mib_tcprow2) is "The PID of the process that issued a context bind for this TCP connection.", so for both ends it will return the pid of the process that called socketpair. Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
2025-01-31 10:57:34 +05:00
// Obnoxious name to make it clear that this is a dangerous operation.
ErrorOr<int> release_underlying_transport_for_transfer();
ErrorOr<IPC::File> clone_for_transfer();
private:
ErrorOr<void> duplicate_handles(Bytes, Vector<size_t> const& handle_offsets);
ErrorOr<void> transfer(ReadonlyBytes);
LibIPC: Port to Windows The Linux IPC uses SCM_RIGHTS to transfer fds to another process (see TransportSocket::transfer, which calls LocalSocket::send_message). File descriptors are handled separately from regular data. On Windows handles are embedded in regular data. They are duplicated in the sender process. Socket handles need special code both on sender side (because they require using WSADuplicateSocket instead of DuplicateHandle, see TransportSocketWindows::duplicate_handles) and on receiver side (because they require WSASocket, see FileWindows.cpp). TransportSocketWindows::ReadResult::fds vector is always empty, it is kept the same as Linux version to avoid OS #ifdefs in Connection.h/.cpp and Web::HTML::MessagePort::read_from_transport. Separate handling of fds permeates all IPC code, it doesn't make sense to #ifdef out all this code on Windows. In other words, the Linux code is more generic - it handles both regular data and fds. On Windows, we need only the regular data portion of it, and we just use that. Duplicating handles on Windows requires pid of target (receiver) process (see TransportSocketWindows::m_peer_pid). This pid is received during special TransportSocketWindows initialization, which is performed only on Windows. It is handled in a separate PR #3179. Note: ChatGPT and [stackoverflow](https://stackoverflow.com/questions/25429887/getting-pid-of-peer-socket-on-windows) suggest using GetExtendedTcpTable/GetTcpTable2 to get peer pid, but this doesn't work because [MIB_TCPROW2::dwOwningPid](https://learn.microsoft.com/en-us/windows/win32/api/tcpmib/ns-tcpmib-mib_tcprow2) is "The PID of the process that issued a context bind for this TCP connection.", so for both ends it will return the pid of the process that called socketpair. Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
2025-01-31 10:57:34 +05:00
private:
NonnullOwnPtr<Core::LocalSocket> m_socket;
ByteBuffer m_unprocessed_bytes;
LibIPC: Port to Windows The Linux IPC uses SCM_RIGHTS to transfer fds to another process (see TransportSocket::transfer, which calls LocalSocket::send_message). File descriptors are handled separately from regular data. On Windows handles are embedded in regular data. They are duplicated in the sender process. Socket handles need special code both on sender side (because they require using WSADuplicateSocket instead of DuplicateHandle, see TransportSocketWindows::duplicate_handles) and on receiver side (because they require WSASocket, see FileWindows.cpp). TransportSocketWindows::ReadResult::fds vector is always empty, it is kept the same as Linux version to avoid OS #ifdefs in Connection.h/.cpp and Web::HTML::MessagePort::read_from_transport. Separate handling of fds permeates all IPC code, it doesn't make sense to #ifdef out all this code on Windows. In other words, the Linux code is more generic - it handles both regular data and fds. On Windows, we need only the regular data portion of it, and we just use that. Duplicating handles on Windows requires pid of target (receiver) process (see TransportSocketWindows::m_peer_pid). This pid is received during special TransportSocketWindows initialization, which is performed only on Windows. It is handled in a separate PR #3179. Note: ChatGPT and [stackoverflow](https://stackoverflow.com/questions/25429887/getting-pid-of-peer-socket-on-windows) suggest using GetExtendedTcpTable/GetTcpTable2 to get peer pid, but this doesn't work because [MIB_TCPROW2::dwOwningPid](https://learn.microsoft.com/en-us/windows/win32/api/tcpmib/ns-tcpmib-mib_tcprow2) is "The PID of the process that issued a context bind for this TCP connection.", so for both ends it will return the pid of the process that called socketpair. Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
2025-01-31 10:57:34 +05:00
int m_peer_pid = -1;
};
}