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

[Oleg.Mihailik at kvazar-micro.com]

Hello, Atsushi Eno,

I am glad to hear this code may be valuable :-)

Last 2 monthes I did no changes in code. Frankly, during this nothes my work was mostly on business WinForms application. I think, I will be busy during next 1-2 monthes, so I cannot make big changes myself.

The greates problem I am worrying today is testing. There are 2 areas, where I am not sure: multithreading (race conditions) and fully valid HTTP/1.1 protocol implementation.

Atsushi, I understand your point on source code style and naming conventions. It is OK to change code. May be I will do it, but I am not sure due to busy time.


I am really INTERESTING what is in archive you attached to mail. Some HttpListener extensions? Very interesting! But it seems it is broken here - 2 Kb tar only. Or may be I use inproper tool to unpack?
 
Thank you, Atsushi Eno. Let me know when my code will be integrated to Mono, it will make me happy these cold days :-)
Have a nice day!
---
Oleg Mihailik, Developer Security MVP
Kyiv, Ukraine


-----Original Message-----
From: Atsushi Eno [mailto:atsushi at ximian.com] 
Sent: Monday, October 31, 2005 9:32 AM
To: Oleg Mihailik
Cc: Miguel de Icaza; mono-list at ximian.com
Subject: Re: [Mono-list] Re: I have System.Net.HttpListener.

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.