[Mono-list] Re: I have System.Net.HttpListener.

[Atsushi Eno]

Hello Oleg,

I was just finding for HttpListener information and came across
your post (several months late); I think it would be nice if this
code could be part of our System.dll.

If you have an updated module, can you please post it again? If
you are not working on it, we can just take over the development.

If you are still on development, I'd ask some things to modify
the code:

	- We use Latin1 for our mcs source code (actually having
	  only ASCII characters is the best for all non-Latin1 people).
	- Code formatting: We have different coding style than VS.NET
	  default.
	  http://www.mono-project.com/Coding_Guidelines
	- It would be better if such sources that are in "Classes",
	  "Threading" and "Collections" are renamed as something like
	  Mono.HttpListener.Impl, or just be inside System.Net.
	- Actually I guess some classes could be unified to single
	  static utility class (such as CharCode.cs and
	  HeaderEncoding.cs).
	- If it is updated to 2.0 RTM API, that would be awesome :-)
	  Now we implemented more 2.0 stuff than we used to have
	  in February.
	- I also wrote some tiny missing bits for HttpListener
	  (actually the HttpListener and related classes themselves
	  but it was not done) attached, in case you don't have.

Many thanks for offering your code for us :-)

Atsushi Eno

Oleg Mihailik wrote:
> Hello, collegues
> 
> I attached package to email. There is VS'03 projects: HttpListener and
> Test. Current status is about 'alpha'.
> 
>> Is this part of the WSE2 stack?
> 
> No, it is absolutely self-contained code. Just 2 bindings:
> mscrolib.dll and System.dll. Even more: my code do not use and was not
> based on any other code except .NET v1.
> 
> 
> And now a little details.
> 
> As you know, fast XML parsers exists in 2 ideologies: event-based and
> read-based. There is SAX and XmlReader. In same manner there is
> different ideologies for HTTP library.
> 
> XSP (as well as Cassini) is mostly 'event-based'. There are workingthreads that polls sockets and when request received ― server
> processing started.
> 
> At other part, HttpListener is completely 'read-based'. There is
> HttpListener.GetContext method, that 'reads' next request. And all
> threading and processing logic must be done on behalf of caller.
> 
> So, such 'read-based' doctrine is first important point.
> 
> 
> Second point is asynchronous processing. There is GetContext and it's
> shadow brothers BeginGetContext and EndGetContext. Easiest way of
> BeginGC/EndGC implementation was using ThreadPool. But it is not good
> for perfomance reason.
> 
> When BeginGetContext spawn ThreadPool's thread, that thread just
> hanging and waiting for request receive completed. Making more waiting
> threads is not shiny design decision.
> 
> So, I implement really asynchronous processing for this methods.
> 
> 
> Next, third important point is global scope of HttpListener's
> prefixes. HttpListener is prefix-based, not address-based. In
> Microsoft's version, you can create:
>   HttpListener1 that listens on "http://localhost/folder1/"
> and
>   HttpListener2 that listens on "http://localhost/folder2/"
> 
> Theese objects can have completely different lifetime. So, there is
> not trivial task ― separating physical EndPointListener from logical
> prefix-bound HttpListener. My code does this task too.
> 
> 
> So, my current care is cleaning and thread-testing. I'm ready to find
> a number of hidden race conditions.
> 
> 
> 
> OK. This is all for now. Have a nice day, Miguel.
> 
> Oleg Mihailik.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: httplistener-missing-bits.tar.bz2
Type: application/octet-stream
Size: 2205 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-list/attachments/20051031/01329d8a/httplistener-missing-bits.tar-0001.obj