Re: another sockets library
- From: "ehuels@xxxxxxxxx" <ehuels@xxxxxxxxx>
- Date: 14 May 2007 04:45:44 -0700
Hi Frank,
On May 13, 2:50 am, Frank Buss <f...@xxxxxxxxxxxxx> wrote:
I've created a small library for asynchronous sockets. They are used in
high performance web servers, like lighthttpd, because you need only one
thread for serving thousands of clients.
http://www.frank-buss.de/lisp/net-0.1.tgz
Currently it is C, only, but platform independant (works on Windows, Mac
OSX and Linux). There is a server and client example.
The goal of this library is to asynchronous server and client sockets for
TCP and UDP. Documentation is in net.h. For Windows I have already created
a Visual Studio .NET project, which creates a DLL and the sample programs.
For Linux and Mac there are shell scripts, which compiles the server and
client program.
The netWait function calls the onNetRead callbacks, if there are some data
for a socket available. With netRead the data will be read non-blocking. If
less data is read than in the OS buffer, the callback will be called again
(this is called level-triggered).
If you write data, it writes as much as possible without blocking. If less
bytes than requested are written, the onWrite callback is called again,
when it is possible to write more bytes without blocking. This is some kind
of edge-triggered, because it is only signalled once, after some data has
been written, and not all the time, when new data can be written. This
concept is used in Windows by default and simulated on the other platforms.
The implementation was a bit difficult, because there are different
underlying concepts on the 3 systems, because the (mostly) platform
independant "select" has a file limit of 64 on Windows and some Linux
systems.
I've seen this remark about Windows sockets and select() a few times
before. Being an author of a sockets library for Lisp myself (and
aiming for
maximum portability - without additional requirements!) I was
triggered by
it and went on a web-seach.
What you see is actually not true, as
http://www.sockets.com/winsock.htm#Deviation_MaxSockets points out:
"The maximum number of sockets which a Windows Sockets application
can make use of is determined at compile time by the manifest
constant
FD_SETSIZE. This value is used in constructing the fd_set structures
used in select(). The default value in winsock.h is 64. If an
application is
designed to be capable of working with more than 64 sockets, the
implementor should define the manifest FD_SETSIZE in every source
file
before including winsock.h. One way of doing this may be to include
the
definition within the compiler options in the makefile, for example
adding
-DFD_SETSIZE=128 as an option to the compiler command line for
Microsoft C. It must be emphasized that defining FD_SETSIZE as a
particular value has no effect on the actual number of sockets
provided by
a Windows Sockets implementation."
Anyway, I hope it helps you to simplify your code where possible. I
intend to
use it myself where I need to in order to make my library's behaviour
match
with most unices.
bye,
Erik.
.
- Follow-Ups:
- Re: another sockets library
- From: Frank Buss
- Re: another sockets library
- References:
- another sockets library
- From: Frank Buss
- another sockets library
- Prev by Date: Re: cl-opengl full package for windows
- Next by Date: Re: comp.lang.lisp grows to 3000 subscribers
- Previous by thread: Re: another sockets library
- Next by thread: Re: another sockets library
- Index(es):
Relevant Pages
|
