Re: Google summer of code
- From: Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx>
- Date: Tue, 18 Apr 2006 00:42:10 +0200
Paolo Amoroso <amoroso@xxxxxxxxx> writes:
Socket API Analysis
http://www.findinglisp.com/blog/2005/12/socket-api-analysis.html
Regarding address representation, I wonder why implementations don't
just wrap the C BSD sockets interface. That is, an address is a pack
of bytes prefixed with an address family. You can always treat the
data as an opaque byte array, and additionally for particular known
address families the implementation provides customized field
accessors. The C interface was designed such that generic address
handling code doesn't have to know address formats. This solves
problems with supporting IPv6, UDP, system-specific protocols etc.
I did this for my language Kogut. An address appears to have fields
family (isomorphic to an integer) and data (a byte array). In addition
addresses appear to have fields which depend on the family. These
fields present data in more convenient formats; they can be used to
access parts of data of an address, or for construction of a new
address. Fields for particular address families include:
* InetFamily - port (integer) and addr (a list of 4 bytes)
* Inet6Family - port (integer), flowInfo (integer),
addr (a list of 16 bytes), scopeId (integer)
* UnixFamily - path (string)
Handlers of fields of particular address families are kept in central
dictionaries, and can be added externally.
The internal representation of an address wraps the C representation,
so it doesn't have to be marshalled when used with socket functions.
Unix provides getaddrinfo() and getnameinfo() for translation of
Internet addresses from/to strings, both in numeric formats and basing
on DNS. On systems which provide these functions, there is no need to
write custom printers and parsers for human-readable IPv4 and IPv6
addresses, and thus IPv6 just works if only the OS supports it.
--
__("< Marcin Kowalczyk
\__/ qrczak@xxxxxxxxxx
^^ http://qrnik.knm.org.pl/~qrczak/
.
- References:
- Re: Google summer of code
- From: Paolo Amoroso
- Re: Google summer of code
- Prev by Date: Re: How Common Lisp sucks
- Next by Date: Re: private data hiding via closures?
- Previous by thread: Re: Google summer of code
- Next by thread: Re: Google summer of code
- Index(es):
Relevant Pages
|
Loading