fbasync - An Asynchronous Facebook API for .NET

Source code checked in

jconley — Wed, 16 Apr 2008 01:09:18 GMT

Added all feed and notification send methods. Moved image args to Utility.

Source code checked in

mdroz8 — Tue, 15 Apr 2008 21:42:13 GMT

needed to add the nunit dll and update the project reference

Source code checked in

mdroz8 — Tue, 15 Apr 2008 19:04:09 GMT

updating readme to provide overview of the fbasync unit tests

Source code checked in

mdroz8 — Tue, 15 Apr 2008 18:35:07 GMT

nunit tests for Utility.cs

Source code checked in

jconley — Sun, 13 Apr 2008 01:27:12 GMT

Moved to using POST for SetProfile support. Added PublishTemplatizedAction -- not yet tested.

UPDATED WIKI: Home

jconley — Sat, 01 Mar 2008 21:03:42 GMT

Project Description
Like the title says, this is an asynchronous Facebook API for .NET. It's designed to be both easy to use and scalable/robust. It assumes a working knowledge of the Facebook developer platform. If you're having scalability or performance issues with the Facebook Developer Toolkit or are concerned with the scalability/performance of your Facebook application, this is the library for you.

Goals

Maximum scalability
High performance
Introduce developers to asynchronous development – It's not that hard!

Scruples
We will not expose synchronous api's for anything that makes a call to the Facebook RESTful API. Synchronous API's to remote web services lead to nothing but heartache (frozen desktop applications, unresponsive web sites, and crashes). Asynchronous programming isn't as hard as you might think. Give it a shot. If you can do AJAX, you can use this library. Read JD's blog for details.

TODO
There is a large TODO list. This project is in its infancy and needs help! It works, but is not quite feature rich enough for a 1.0 release. Hopefully sometime soon we'll have something respectable to release. For now, grab the 0.1 release and have a go!

NEW POST: Using the Worker Process' ThreadPool or not?

jconley — Sat, 16 Feb 2008 19:18:03 GMT

The latest version in source control has the async fix I was talking about. Sorry I took so long to get to this. Finally had a reason to use this in the real world! The data is now streamed asynchronously from Facebook and buffered into a MemoryStream. The MemoryStream is then read to hydrate the objects. You should see a big improvement in the usage of IOCP threads.

Source code checked in

jconley — Fri, 15 Feb 2008 17:54:31 GMT

New files for group and event support, and an error log.

Source code checked in

jconley — Fri, 15 Feb 2008 17:53:16 GMT

Removed last bit of synchronous code in FacebookConnection. Removed storage of connection in Session state.

Source code checked in

jconley — Thu, 14 Feb 2008 07:29:41 GMT

Group/Event photo functionality!

UPDATED WIKI: Home

jconley — Tue, 05 Feb 2008 01:56:48 GMT

Maximum scalability
High performance
Introduce developers to asynchronous development – It's not that hard!

Scruples
We will not expose synchronous api's for anything that makes a call to the Facebook RESTful API. Synchronous API's to remote web services lead to nothing but heartache (frozen desktop applications, unresponsive web sites, and crashes). Asynchronous programming isn't as hard as you might think. Give it a shot. If you can do AJAX, you can use this library. Read JD's blog for details.

TODO
There is a large TODO list. This project is in its infancy and needs help! It works, but is not quite feature rich enough for a 1.0 release. Hopefully sometime in February, 2008 we'll have something respectable to release (that's the goal, anyway). For now, grab the 0.1 release and have a go!

Source code checked in

jconley — Tue, 05 Feb 2008 01:54:38 GMT

Fixed serialization issue with FacebookEntity. Moved to long UID instead of string.

NEW POST: Using the Worker Process' ThreadPool or not?

jconley — Wed, 19 Dec 2007 21:58:47 GMT

Oh, to answer your question, using our own threadpool in this case would be a bad idea. Instead we should fix the design flaw and asynchronous read the response data.

There are very few instances where using your own threadpool is a good idea. The major one is when you are performing tasks that will block on I/O and you have no control over them. For example, if you're making a lot of calls out to LDAP or using another library that does I/O without exposing asychronous interfaces, it might be a good idea to have a small threadpool of your own and queue requests through it.

NEW POST: Using the Worker Process' ThreadPool or not?

jconley — Wed, 19 Dec 2007 21:54:13 GMT

I see your point. It was the intent of the library to never tie up a thread unless it was doing CPU intensive tasks. However, in real life, it appears there is one spot where that is not so.

I think the effects of an early design decision (laziness) are popping up with the amount of time the IOCP thread is tied up. Right now, the initial request is asynchronous (so your worker threads exit immediately). However, the reading of the response is not. I am just shoving the response stream into a Xml reader, which is going to synchronously read. That is likely what is tying up your IOCP thread. What the library should be doing, to be fully asynchronous, is using BeginRead on the response stream and shoving chunks of the response at a time into a local MemoryStream. That way we would effectively never be blocking in an IOCP thread. I'll make this change soon. Or, if you're feeling adventurous have a look at the code and give it a whirl! :) If you have a look at the FacebookConnection.WebResponseCallback method you see that I'm just grabbing the response stream and marking the request as complete. Instead of setting the response complete there, we should kick off a BeginRead process on the response stream, and write the data into a MemoryStream. When we're done reading (asynchronously) from the response stream, the result should be set to the MemoryStream we created, instead of the Http response stream. This will eliminate the last of the blocking in the library and you should hardly ever see any IOCP threads in use.

Here's a great article on the entire ASP.NET life-cycle, specifically related to threading and request processing: http://blogs.msdn.com/nicd/archive/2007/04/16/dissection-of-an-asp-net-2-0-request-processing-flow.aspx It's even up to date!

NEW POST: Using the Worker Process' ThreadPool or not?

tomten — Thu, 13 Dec 2007 23:23:24 GMT

Hm, just to make sure we're talking about the same thing, I'm going to state alot of obvious things: The managed threadpool consists of worker threads and IOCP threads. According to MSDN, the default is 25 for both, multiplied by the number of CPUs. As long as BeginProcessRequest() in an asynchronous ASP.NET page is executing, 1 managed worker thread will be in use by the page (i.e. for a very short time). Also, as long as Facebook and the page are engaged in HTTP conversation, 1 managed IOCP thread will be in use (a few hundred milliseconds for me; it might be faster for someone who doesn't have to cross an ocean to reach the Facebook servers). A managed IOCP thread is used because BeginGetResponse() uses Winsock2 and IOCP internally, but if it were to, say, Queue a UserWorkItem, a managed worker thread would be used instead (on Mono, perhaps it will). This is what I mean by a thread being "tied up". So if I'm not mistaken; for 25 managed IOCP threads, there can only be 25 (actually, I think it's 23, because of the contention safeguards) Facebook API calls in action simultaneously. Right? If I monitor the threadpool when using fbasync, I can verify all this. Or have I missed something?

The point I was trying to raise is that using custom threads is more expensive but perhaps also more scalable. I was wondering whether you had given any thought to that, and if so, what conclusions you had reached. =]

http://msdn2.microsoft.com/en-us/library/ms979194.aspx

UPDATED WIKI: Home

jconley — Thu, 13 Dec 2007 21:19:18 GMT

Maximum scalability
High performance
Introduce developers to asynchronous development – It's not that hard!

Scruples
We will not expose synchronous api's for anything that makes a call to the Facebook RESTful API. Synchronous API's to remote web services lead to nothing but heartache (frozen desktop applications, unresponsive web sites, and crashes). Asynchronous programming isn't as hard as you might think. Give it a shot. If you can do AJAX, you can use this library. Read JD's blog for details.

TODO
There is a large TODO list. This project is in its infancy and needs help! It works, but is not quite feature rich enough for a 1.0 release. Hopefully by February, 2008 we'll have something respectable to release (that's the goal, anyway). For now, grab the 0.1 release and have a go!

UPDATED WIKI: Home

jconley — Thu, 13 Dec 2007 21:18:45 GMT

Maximum scalability
High performance
Introduce developers to asynchronous development – It's not that hard!

Scruples
We will not expose synchronous api's for anything that makes a call to the Facebook RESTful API. Synchronous API's to remote web services lead to nothing but heartache (frozen desktop applications, unresponsive web sites, and crashes). Asynchronous programming isn't as hard as you might think. Give it a shot. If you can do AJAX, you can use this library. Read JD's blog for details.

TODO
There is a large TODO list. This project is in its infancy and needs help! It works, but is not quite feature rich enough for a 1.0 release. Hopefully by February, 2008 we'll have something respectable to release (that's the goal, anyway). For now, grab the 0.1 release and have a go!

NEW POST: Using the Worker Process' ThreadPool or not?

jconley — Thu, 13 Dec 2007 20:59:45 GMT

I'm fairly certain it will end up back in the ASP.NET worker threadpool through the synchronization context, but I don't know for certain either. It's definitely unclear in the documentation. In either case, there is one thing not quite right about your statement above: "isn't that a bit long to be tying up a threadpool thread?". There is in fact never a thread tied up. That's the whole point of the asynchronous patterns. :) Notice in the sample code (and way down deep in the source) it is never waiting for a request to return. We delegate that responsibility all the way down to the Windows socket layer which uses shared I/O, IOCP, and other magic to fire a callback when data has been received on the socket. Nothing is every tying up a thread.

Oh, and Facebook calls don't typically take 250ms in my experience, though I have seen that happen on occasion. Just like any big service, they, or the internet, can have slowdowns.

NEW POST: Using the Worker Process' ThreadPool or not?

tomten — Thu, 13 Dec 2007 19:15:12 GMT

According to MSDN (see below), some Fx BCL functions used by fbasync use the managed threadpool internally. Wouldn't it be better to use a custom threadpool to avoid ASP.NET worker process threadpool contention? Web requests to Facebook usually take between 250 and 500(?) ms; isn't that a bit long to be tying up a threadpool thread?

http://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.begingetresponse.aspx

EDIT: Actually, after reading up on the subject, I can't find a verifiable source as to whether or not (e.g.) BeginGetResponse() uses the same managed threadpool available to ASP.NET. It seems to vary with at least the IIS version and the Windows version. I'm assuming that on Windows Server 2003 and its IIS, BeginGetResponse() uses an IOCP thread outside of the worker process. Could you point me somewhere that has hard facts on this?

UPDATED RELEASE: 0.1 (Dec 11, 2007)

Wed, 12 Dec 2007 06:40:06 GMT

*fbasync 0.1*
The features that are here are reliable enough to be used in production code, but we're a ways from a feature complete 1.0. The public API is also still subject (and likely) to change. The source download is currently the only one available. It contains the source code and a sample application.

*What it has*
* Asynchronous I/O for Facebook RESTful API requests.
* FQL support.
* Profile update support.
* Strongly typed Photo/Album/User read support.
* Base page class in ASP.NET for easy usage.
* Photo album browser application example.

*What it is missing*
* Tests
* Most of the RESTful api calls are not implemented.
* More examples.
* A help file.
* Visual Studio templates.
* An installation package.
* Lots of controls and things that haven't been thought of yet.
* Easy to use components for web and desktop.
* ASP.NET MVC helpers.