I'll be able to look into this when I get back from vacation next week if
no one else gets there first.

On 27 June 2017 at 22:18, Roland Knall <[email protected]> wrote:

> This is one of the best and most comprehensive explanations for Windows
> sockets I read so far.
>
> @Stig - You could take a look at extcap_spawn.c, there you will find code,
> also in extcap.c for implementing waiting on that thing, Windows likes to
> call a "Named Pipe"
>
> cheers,
> Roland
>
> On Tue, Jun 27, 2017 at 10:59 PM, Guy Harris <[email protected]> wrote:
>
>> (Sending to a broader list, in case anybody has answers.)
>>
>> On Jun 26, 2017, at 10:53 AM, Stig Bjørlykke <[email protected]> wrote:
>>
>> > The extcap interface toolbar is not supported on Windows yet,
>> > basically because I don't know how the pipe handling is done when
>> > using select(),
>>
>> Sadly, Windows' handling of "wait for something to happen" is a bit
>> clumsier than UN*X's.
>>
>> UN*Xes have select() and poll(), with the possible addition of some other
>> similar mechanisms such as Linux's epoll() or *BSD/Darwin's kqueues.  You
>> can wait for a device, a socket, or a pipe with them.  (Sadly, in the
>> general case, you can't wait for a process or thread to terminate with
>> select(), although you can do it with kqueues on at least some platforms.
>> I'm not sure whether the inability to wait for a mutex to unlock or a
>> condition variable to be signaled is a significant issue or not.)
>>
>> Windows has select()
>>
>>         https://msdn.microsoft.com/en-us/library/windows/desktop/ms7
>> 40141(v=vs.85).aspx
>>
>> which works on sockets, sockets, sockets, and sockets, and
>> WaitForMultipleObjects():
>>
>>         https://msdn.microsoft.com/en-us/library/windows/desktop/ms6
>> 87025(v=vs.85).aspx
>>
>> which works on a number of things - only one of which is the equivalent
>> of a readable file descriptor, namely "console input".  It doesn't appear
>> that you can use a HANDLE for a pipe (named or unnamed), and, while
>> Microsoft seem to indicate that you can do regular ReadFile()/WriteFile()
>> I/O on a socket:
>>
>>         https://msdn.microsoft.com/en-us/library/windows/desktop/ms7
>> 40522(v=vs.85).aspx
>>
>> they don't indicate what the connection is between a socket descriptor
>> and a socket handle (they have the same size, 32 bits in Win32 and 64 bits
>> in Win64, but are SOCKET values usable as HANDLEs, or is there a "get a
>> handle for this socket descriptor" call?) - and even if you get a HANDLE it
>> probably works no better with WaitForMultipleEvents() than do pipe HANDLEs.
>>
>> For named pipes, you can use "overlapped mode" for asynchronous I/O:
>>
>>         https://msdn.microsoft.com/en-us/library/aa365788(VS.85).aspx
>>
>> and can create an event handle that's signaled when a read or write
>> completes, and hand *that* to WaitForMultipleObjects().  This appears, from
>> some Web searching, to be the closest thing to waiting for a read to be
>> possible, but it would be done differently - instead of
>>
>>         select();
>>         if (pipe is readable) {
>>                 read into buffer;
>>                 process that data if we can;
>>         }
>>
>> it'd be more like
>>
>>         start an asynchronous read into the buffer;
>>         WaitForMultipleObjects();
>>         if (event for that pipe was triggered) {
>>                 process the data that was read if we can;
>>         }
>>
>> Anonymous pipes are just named pipes with created unique names:
>>
>>         https://msdn.microsoft.com/en-us/library/aa365141(v=vs.85).aspx
>>
>> but, as that page says, "Asynchronous (overlapped) read and write
>> operations are not supported by anonymous pipes.".
>>
>> For sockets, it appears you can do an operation that's similar to
>> select(), but, instead of waiting, returns an event handle:
>>
>>         https://msdn.microsoft.com/en-us/library/windows/desktop/ms7
>> 41576(v=vs.85).aspx
>>
>> However, those event handles may, or may not, be like regular Windows
>> event handles; they are documented as working with
>> WSAWaitForMultipleEvents() rather than with WaitForMultipleObjects():
>>
>>         https://msdn.microsoft.com/en-us/library/windows/desktop/ms7
>> 42219(v=vs.85).aspx
>>
>> and they also don't indicate whether you can use regular event objects
>> with WSAWaitForMultipleEvents().
>>
>> Furthermore, GUI applications should probably use
>> MsgWaitForMultipleObjects().  I think that's what's used in the GUI event
>> loops of GTK+ and Qt on Windows.
>>
>> So doing the equivalent of select()/poll() on Windows appears to be a
>> challenge.
>>
>> If anybody has more information than what I found, that'd be helpful.
>> ____________________________________________________________
>> _______________
>> Sent via:    Wireshark-dev mailing list <[email protected]>
>> Archives:    https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>              mailto:[email protected]?subject=unsubscr
>> ibe
>
>
>
> ____________________________________________________________
> _______________
> Sent via:    Wireshark-dev mailing list <[email protected]>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:[email protected]?subject=
> unsubscribe
>



-- 
Graham Bloice
Software Developer
Trihedral UK Limited
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to