Shulou(Shulou.com)06/02 Report--

f#Simple Comet chat service example analysis, in response to this problem, this article details the corresponding analysis and solution, hoping to help more small partners who want to solve this problem find a simpler and easier way.

Visual Studio 2010 is already known for F#, so how do you develop it? Here the author will be able to use C#development examples, instead of F#to carry out, but also for everyone to broaden their horizons.

Normal Web applications are maintained by a large number of HTTP short connections. For example, when implementing a chat service, the client will constantly poll the server for new messages. The advantage of this approach is that it is simple and effective, so it is widely used by current chat services. Comet technology, however, is different. Simply put, Comet refers to server-push technology. This is done (only browser-based Web platforms are discussed here) by establishing a long connection between the browser and the server and returning immediately after receiving the message. Otherwise, wait until timeout. Once the client gets the message or times out, another long connection is established. The best advantage of Comet technology is naturally high reliability.

If you want to implement Comet technology on the ASP.NET platform, you naturally need to use asynchronous request processing on the server side. If it is a normal processing mode, each request will occupy a worker thread. You should know that Comet is a "long connection", so it does not take many clients to occupy a large number of threads, which is huge for resource consumption. If the request is asynchronous, although the connection between the client and the server is maintained, the client does not occupy the thread while waiting for the message, and does not continue to execute until "timeout" or "message arrival".

A Comet service prototype based on ASP.NET has been implemented before, but using C#. Now we use F#to implement this function. You'll find F#has unique advantages for this type of asynchronous scenario.

A common unit of work in F#is a module, in which a large number of functions or fields are defined. For example, if we want to build a chat service, I define a Chat module:

#light module internal Comet.Chating.Chat open System open System.Collections.Concurrent type ChatMsg = { From: string; Text: string; } let private agentCache = new ConcurrentDictionary>() let private agentFactory = new Func>(fun _ -> MailboxProcessor.Start(fun o -> async { o |> ignore })) let private GetAgent name = agentCache.GetOrAdd(name, agentFactory)

Here I build a Record type called ChatMsg, where a ChatMsg object is a message. Then, I use a ConcurrentDictionary object called agentCache to hold the chat queue for each user-MailboxProcessor. It is built into the F#core library for message-passing concurrency and is very lightweight, so I allocate one for each user and use very few resources. GetAgent function is used to obtain the corresponding MailboxProcessor object according to the user's name, needless to say.

Chat module also defines send and receive two public methods, as follows:

let send fromName toName msg = let agent = GetAgent toName { From = fromName; Text = msg; } |> agent.Post let receive name = let rec receive' (agent: MailboxProcessor) messages = async { let! msg = agent.TryReceive 0 match msg with | None -> return messages | Some s -> return! receive' agent (s :: messages) } let agent = GetAgent name async { let! messages = receive' agent List.empty if (not messages.IsEmpty) then return messages else let! msg = agent.TryReceive 3000 match msg with | None -> return [] | Some s -> return [s] }

The send method takes three arguments and returns no value, and its implementation simply constructs a ChatMsg object and plugs it into the corresponding MailboxProcessor. But the receive method is the most critical part here (none of it). The receive function accepts and returns an object already in MailboxProcessor, or waits 3 seconds for a timeout--which is not appropriate, because the receive method simply constructs an Async Workflow that "does this" without actually executing it. As to how it is executed, we will talk about it later.

The logic of the receive function goes like this: First we construct a helper function receive'to "try to get" all the messages already in the queue. receive'is a recursive function that takes one at a time and recursively takes the rest of the messages. The agent.TryReceive function accepts 0, which means the query queue, and immediately returns an Option result. If this result is None, it means the queue is empty. Therefore, in the main function of receive, first use the receive'function to obtain the existing message. If there is one, it will return immediately. Otherwise, it will receive *** messages obtained within 3 seconds. If it has not been received at the end of 3 seconds, it will return None.

Let! is used in both receive and receive'functions. Gets the result of the agent.TryReceive function. let! F#is the keyword for constructing Workflow, which plays the role of "syntactic sugar." For example, the following Async Workflow:

async { let req = WebRequest.Create("http://moma.org/") let! resp = req.GetResponseAsync() let stream = resp.GetResponseStream() let reader = new StreamReader(stream) let! html = reader.ReadToEndAsync() html }

In fact, after "sugar removal," it becomes:

async.Delay(fun () -> async.Let(WebRequest.Create("http://moma.org/"), (fun req -> async.Bind(req.GetResponseAsync(), (fun resp -> async.Let(resp.GetResponseStream(), (fun stream -> async.Let(new StreamReader(stream), (fun reader -> async.Bind(reader.ReadToEndAsync(), (fun html -> async.Return(html))))))))))

let! Keywords are converted into Bind function calls, Bind calls have two parameters, *** parameters are Async

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.