Le 29 déc. 2017 à 12:31, Richard Hipp a écrit :
>> In my own code, I generally end up including:
>>
>> #include
>> #include
>> #include
>>
>> in code units using MS winsock.
>>
>> I'll soon see what would fit for fossil win32 networking.
>
> Please keep in mind that
On 12/29/17, Olivier Mascia wrote:
>> Le 29 déc. 2017 à 01:17, Richard Hipp a écrit :
>>
>> On 12/28/17, Olivier Mascia wrote:
>>> To get a proper dual-stack socket, the socket must be created with
>>> AF_INET6
>>> first then setsockopt(s,
> Le 29 déc. 2017 à 01:17, Richard Hipp a écrit :
>
> On 12/28/17, Olivier Mascia wrote:
>> To get a proper dual-stack socket, the socket must be created with AF_INET6
>> first then setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,...)
>
> When I try to do this I get:
> Le 29 déc. 2017 à 02:30, Richard Hipp a écrit :
>
> On 12/28/17, Thomas wrote:
>>
>> This could be an option too:
>> #ifndef IPV6_V6ONLY
>> #define IPV6_V6ONLY 27
>> #endif
>
> It compiles with that. But it doesn't work. So for now, I think
> we'll
On 12/28/17, Thomas wrote:
>
> This could be an option too:
> #ifndef IPV6_V6ONLY
> #define IPV6_V6ONLY 27
> #endif
It compiles with that. But it doesn't work. So for now, I think
we'll just stick with IPv4-only servers for "fossil server" on windows
- at least until
Oh, and this is not a Windows thingy.
For Linux:
#include
#include
http://man7.org/linux/man-pages/man7/ipv6.7.html
On 2017-12-29 02:23, Thomas wrote:
On 2017-12-29 01:17, Richard Hipp wrote:
On 12/28/17, Olivier Mascia wrote:
To get a proper dual-stack socket, the
On 2017-12-29 01:17, Richard Hipp wrote:
On 12/28/17, Olivier Mascia wrote:
To get a proper dual-stack socket, the socket must be created with AF_INET6
first then setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,...)
When I try to do this I get: error C2065: 'IPV6_V6ONLY':
On 12/28/17, Olivier Mascia wrote:
> To get a proper dual-stack socket, the socket must be created with AF_INET6
> first then setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,...)
When I try to do this I get: error C2065: 'IPV6_V6ONLY': undeclared identifier
MSVC 2015
--
D. Richard
Thus said Warren Young on Thu, 28 Dec 2017 08:20:21 -0700:
> I'm pretty sure I've never seen Fossil crash in the years I've been
> running it.
I've had it dump core a few times but those were generally due to bugs
that were quickly fixed.
Andy
--
TAI64 timestamp: 40005a4540f3
> Le 28 déc. 2017 à 17:37, Olivier Mascia a écrit :
>
> The quick/easy/dirty/temporary fix before completing the proper support
> (server-side) of IPv4+IPv6 would be to simply adjust the hint.ai_family
> initialisation in http_socket.c::socket_open to read:
>
> #ifdef _WIN32
> Le 28 déc. 2017 à 17:18, Richard Hipp a écrit :
>
> There is one thread per connection in the parent process, which allows
> the parent to manage multiple simultaneous incoming connections. As
> each thread gets a complete HTTP request, it writes that request into
> a
> Le 28 déc. 2017 à 16:55, Olivier Mascia a écrit :
>
>> I'll experiment with the fossil code here. Familiarizing with winhttp.c for
>> now.
>
> I haven't yet come to bottom of it, but using IP (IPv4) in the URL (instead
> of name) changes it all!! There seem to be a high
On 12/28/17, Warren Young wrote:
>>
>> Even the Windows server starts a new process to handle each request.
>> It just does so using system() rather than fork().
>
> That leaves me wondering what the threads are used for then, if not to
> implement a thread-per-connection
On Dec 28, 2017, at 9:11 AM, Richard Hipp wrote:
>
> On 12/28/17, Warren Young wrote:
>>
>> drh, I seem to recall messages about non-free()’d buffers in the Fossil
>> server code, where the patch was rejected with the argument that the forked
>> child is
On 12/28/17, Warren Young wrote:
>
> drh, I seem to recall messages about non-free()’d buffers in the Fossil
> server code, where the patch was rejected with the argument that the forked
> child is about to die anyway, so why bother freeing the buffer. That
> doesn’t really
On Dec 28, 2017, at 8:55 AM, Olivier Mascia wrote:
>
>> Le 28 déc. 2017 à 15:42, Olivier Mascia a écrit :
>>
>> I'll experiment with the fossil code here. Familiarizing with winhttp.c for
>> now.
>
> I haven't yet come to bottom of it, but using IP (IPv4)
> Le 28 déc. 2017 à 15:42, Olivier Mascia a écrit :
>
> I'll experiment with the fossil code here. Familiarizing with winhttp.c for
> now.
I haven't yet come to bottom of it, but using IP (IPv4) in the URL (instead of
name) changes it all!! There seem to be a high price
On Dec 28, 2017, at 7:42 AM, Olivier Mascia wrote:
>
> server on macOS, client on Windows (server 2016 and server 2012 R2) is OK.
> Server and client on same Windows box, through localhost is comparable (just
> slightly slower) to server macOS and client Windows.
That’s not
On Dec 28, 2017, at 6:11 AM, Olivier Mascia wrote:
>
> *** time skew *** server is slow by 106.6 seconds
…snip…
> I'll have a close look in the next weeks at the source code of the Windows
> server feature of Fossil. The warning "*** time skew *** will certainly be
>
On Dec 28, 2017, at 4:26 AM, Olivier Mascia wrote:
>
> Is "fossil server" generally deemed sufficient for a small LAN (lab) of let's
> say < 10 developers each with their own clone ?
> Or should a proper HTTP server be used as front end to SCGI mode of fossil?
That’s how I
> Le 28 déc. 2017 à 15:04, Richard Hipp a écrit :
>
> On 12/28/17, Richard Hipp wrote:
>>
>> Running multiple copies of the new fossil-stress.tcl script
>> (https://www.fossil-scm.org/fossil/file/tools/fossil-stress.tcl) from
>> a linux box against a windows
On 12/28/17, Richard Hipp wrote:
>
> Running multiple copies of the new fossil-stress.tcl script
> (https://www.fossil-scm.org/fossil/file/tools/fossil-stress.tcl) from
> a linux box against a windows laptop confirms that the "fossil server"
> command on Windows sometimes latches
On 12/28/17, Richard Hipp wrote:
>
> The "fossil server" command *should* be sufficient for this. However,
> it doesn't get used that much. Most people run from a proper HTTP
> server of some kind. Consequently, it is possible for bugs to linger
> in "fossil server" without
> Le 28 déc. 2017 à 13:51, Richard Hipp a écrit :
>
> On 12/28/17, Olivier Mascia wrote:
>>
>> Is "fossil server" generally deemed sufficient for a small LAN (lab) of
>> let's say < 10 developers each with their own clone ?
>> Or should a proper HTTP server
On 12/28/17, Olivier Mascia wrote:
>
> Is "fossil server" generally deemed sufficient for a small LAN (lab) of
> let's say < 10 developers each with their own clone ?
> Or should a proper HTTP server be used as front end to SCGI mode of fossil?
The "fossil server" command
> Le 28 déc. 2017 à 12:26, Olivier Mascia a écrit :
>
> Dear,
>
> Is "fossil server" generally deemed sufficient for a small LAN (lab) of let's
> say < 10 developers each with their own clone ?
> Or should a proper HTTP server be used as front end to SCGI mode of fossil?
>
>
Dear,
Is "fossil server" generally deemed sufficient for a small LAN (lab) of let's
say < 10 developers each with their own clone ?
Or should a proper HTTP server be used as front end to SCGI mode of fossil?
From some quick-n-dirty tests (yeah, on a Windows server, not the best of all
ideas
27 matches
Mail list logo