Thanks all.
Both UNIX and Windows will return EINPROGRESS and WSAEWOULDBLOCK
successively after a non blocking connect. [I was confused about this before
but now I understand it.]
The difference between UNIX and Windows is in the select system call that
comes after the connect call.
On UNIX the
Hi and thanks for your continued help!
Meanwhile I did indeed define the syntax of the extension and get my way
through to the leaf being an ASN1_OBJECT representing the professionOID. Now my
lack of knowledge strikes back:
I want to check, whether a professionOID of 1.2.276.0.76.4.88 is
* David Schwartz wrote on Sun, Aug 23, 2009 at 15:40 -0700:
My question is why _using the same code_ Windows is returning
WSAEWOULDBLOCK instead of WSAECONNREFUSED when my server is down?
while UNIX correctly returns ECONNREFUSED...
Because Windows cannot tell whether your server is down
Hello,
since Firefox 3.5 apparently doesn't accept Root CA self signed
certificate which doesn't contain correct extensions (Basic Constraints:
CA:TRUE)
I wonder how I can add these extensions to my already existing and self
signed Root CA :
Md Lazreg wrote:
On UNIX the select will return after signaling the write set
[ as documented].
On Windows the select will return after signaling the _error_
set [The MSDN documentation says that you need to check the write set].
That makes no sense.
My problem was that my select was
With my new code, if my server is overloaded and cannot accept a connection
immediately, my Windows client does not wait the whole timeout. This is the
behavior I want. I do not want it to be sitting there just in case my server
becomes available again or is on the process of being restarted.
My
Md Lazreg wrote:
It is possible that the previous Windows behavior is correct but that
is not the behavior I want.
I think you are incorrect about that.
I want the same behavior as UNIX which in my opinion is what my clients
would want. My clients can connect to a set of servers in a raw,
It seems that after setting FIPS mode off one cannot set it back on again in
the same executable.
I have a test program which does:
FIPS_mode_set(1) - works ok indicated by a return true.
FIPS_mode_set(0) - to turn off and works ok, at least the FIPS_mode() call
returns 0, so it seems to be
Mike Trent wrote:
It seems that after setting FIPS mode off one cannot set it back on again
in the same executable.
I have a test program which does:
FIPS_mode_set(1) - works ok indicated by a return true.
FIPS_mode_set(0) - to turn off and works ok, at least the FIPS_mode() call
