FW: Where in a NSPR socket object is the actual file descriptor (fd)?
Hello, If I were to use the PR_FileDesc2NativeHandle function to get to the actual fd of a NSPR socket, and then used this fd in a select or poll call (non NSPR calls) to do multiplexing of I/O, should any consideration be given to whether the NSPR socket is a SSL layered socket or a plain NSPR socket? In other words, Julien Pierre said at one point (this discussion originally started in the mozilla.nspr newsgroup): If it's an NSS socket doing SSL, the fact that there is data on it doesn't necessarily mean that it's application data. You should only read from that socket with NSPR functions, never OS functions So the better question is then: if my application uses NSS sockets doing SSL, and at some point I get the corresponding native fd as described above, use it in a select call, and the latter detects I/O on the fd, can I safely then call PR_Read on the original NSS socket? -- POC -Original Message- From: Wan-Teh Chang [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 08, 2002 10:49 PM To: [EMAIL PROTECTED] Subject: Re: Where in a NSPR socket object is the actual file descriptor (fd)? Patrick wrote: Where in a NSPR socket object is the actual file descriptor (fd)? The actual fd can be retrieved with the semi-private function PR_FileDesc2NativeHandle function, declared in private/pprio.h. This function is supported but must only be used when there is no alternative. It heavily depends on the properties of the current NSPR implementation. Has anyone actually use this fd in a select or poll call (non NSPR calls)? Yes. You should also consider using the PR_CreateSocketPollFd function, also declared in private/pprio.h. PR_CreateSocketPollFd is a better method than PR_FileDesc2NativeHandle because it does not depend on the current implementation of NSPR. PR_CreateSocketPollFd gives your native fd's just enough NSPR file descriptor wrapping so that they can be operated on by PR_Poll. It allows you to poll on a combination of native fd's and NSPR file descriptors. Wan-Teh
Problems getting client certs into cert-store
I've developed an open-source based Certificate Authority software package called Papyrus and previously (i.e. Netscpae 4x) I was able to use application/x-x509-email-cert and cat a PEM cert to the browser and it would invoke the certificate management to import the user cert to allow for encryption. This isn't working in Moz1.1b (and possibly previous versions) and was wondering if something changed and I'm doing something wrong to try and get the certs into the browser store. Any assistance would be greatly appreciated, - John Douglass, Georgia Institute of Technology
certutil failure to load dynamic library
I can use certutil to create the cert dbs and generate key pairs, but when I try to list the keys, I get the message certutil: no keys found: Failure to load dynamic library. All the dependent libraries are in the same directory as certutil.exe: libplc4.dll, libplds4.dll, libnspr4.dll. Any ideas?
HOT NEW ADULT ONLY CHAT FORUM 9223
Stop by and check it out !!! Pantyhose Top now has a really kewl message board that's open to ALL !!! General Chat, Pantyhose Chat, Nylon Chat, Stories and much much more http://www.pantyhose-top.com
Re: FW: Where in a NSPR socket object is the actual file descriptor(fd)?
Cesard, Patrick O. wrote: Hello, If I were to use the PR_FileDesc2NativeHandle function to get to the actual fd of a NSPR socket, and then used this fd in a select or poll call (non NSPR calls) to do multiplexing of I/O, should any consideration be given to whether the NSPR socket is a SSL layered socket or a plain NSPR socket? In other words, Julien Pierre said at one point (this discussion originally started in the mozilla.nspr newsgroup): If it's an NSS socket doing SSL, the fact that there is data on it doesn't necessarily mean that it's application data. You should only read from that socket with NSPR functions, never OS functions What I meant by the above is that the incoming socket data that's been detected might be data for the SSL handshake. Obviously you can't process that with a native recv() or read() call, or you will get garbage. You must use PR_Recv() or PR_Read(). So the better question is then: if my application uses NSS sockets doing SSL, and at some point I get the corresponding native fd as described above, use it in a select call, and the latter detects I/O on the fd, can I safely then call PR_Read on the original NSS socket? You should use PR_Recv() for this case, not PR_Read(). If the incoming data is only handshake data but the peer didn't send any application data, a PR_Read() will block your thread until there is application data actually available from the peer. So you should call PR_Recv() with a timeout of zero instead. This may return no data and seemingly do nothing from your application point of view, but underneath it will in fact consume the SSL handshake data to continue the handshake processing. Similar logic may be needed for other types of (non-SSL) NSPR layering that you can define yourself, which may use headers that are discarded in the layer and never passed to the application. In that case, just like SSL, there is socket data but not necessarily application data. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
