[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-users] Re: ... and a happy new year as well!
From: |
Ivan Shmakov |
Subject: |
[Chicken-users] Re: ... and a happy new year as well! |
Date: |
Sat, 09 Jan 2010 14:52:09 +0600 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
>>>>> "NP" == Nicolas Pelletier <address@hidden> writes:
>>>>> "IS" == Ivan Shmakov <address@hidden>:
IS> PS. Currently, I'm about to begin my preparations for the course
IS> on computer networks I'd be carrying on for the second time. While
IS> no part of the course the course has a specific focus on the
IS> network programming, I'd be glad to hear any suggestions on how
IS> Scheme (and functional programming in general) could be mentioned.
NP> I'd suggest protocol analysis or traffic inspection. Chicken's
NP> support for low-level access and easy ffi lets you hook almost
NP> anywhere in the network stack.
Does it? The significant portion of the network stack is
implemented in the kernels of the systems I know, and, IIUC,
embedding Chicken into a (monolithic) kernel is unlike a clever
idea. (Though making Chicken capable of doing Hurd IPC may be
interesting. At the very least, it will allow implementing Hurd
filesystem drivers in Scheme with much less the risk of crashing
the whole system.)
Although interferring with the kernel's own handling of the
messages is possible (at least on GNU/Linux, thanks to, in
particular, the TUN/TAP facility), it doesn't seem to be a thing
that fits the time constraints of the course. ... Or?
NP> Then Scheme's power lets you use more advanced tools for analysis
NP> (e.g. using a true parser to analyze a protocol, for example with
NP> the packrat egg).
Won't that require some introduction into parsing in general?
The protocols with fixed-length headers are easier in that
respect. Does Chicken has easy support for these?
NP> On top of that, you can hook some reasoning capabilities (for
NP> example, with the kanren egg)
Yet again, doesn't that imply some prior knowledge of the
declarative programming?
NP> to detect intrusions, attacks, questionnable traffic,
These tasks seem to require fast response of the system. Is
kanren capable of that?
Note also that, potentially, the program will have to be able to
process up to tens of MiB per second in real-life
configurations. I'm in doubt that any implementation of a
sufficiently sophisticated algorithm will fit the time
constraints of the task.
NP> or suggest an optimal network configuration, etc...
?
NP> Or you can go for server-side programming, for example cgi,
Do you mean writing CGI in Scheme? Are there specific
advantages over the other (high-level) languages?
NP> connection pooling, access policy... or even (gasp!) cloud
NP> computing (for example, cluster or cloud controllers);
Well, to the extent I'm into this problem, I don't see anything
to preclude the use of Scheme for that. Moreover, there're some
experiments that are being carried over here on distributed
computing which may benefit of such software. However, I don't
see at the moment how this task may fit the course.
NP> the kind of thing that is traditionally done in C with complicated
NP> data structures, a lot of pointers, and no help from GC, closures,
NP> or symbolic programming. And takes a lot of effort and money to
NP> develop and debug :-)
I guess that it's going to be a lot of effort to implement it in
whatever language. Or are there examples of the contrary?
NP> Another hot topic today is the semantic web (RDF, OWL and friends).
NP> This is an area where high-level languages with dynamic and
NP> reasoning capabilities (e.g. Scheme, Lisp, Prolog, for example)
NP> shine.
Alas, I don't think I'm keen enough on these topics.
NP> Whether you want to see the network from behind HTTP or not is up
NP> to you, of course.
I'm not sure about RDF, etc., but I've got a habit of thinking
of XML separately from HTTP. To my mind, both may be used (and,
indeed, are used quite widely) independently of one another.
NP> That's it for a few ideas.
Thanks.
--
FSF associate member #7257
pgpGOFVjOB7Qz.pgp
Description: PGP signature