That callback is called when there is a request and you need to put in
your logic to deliver a response.
What kind of error could pop up during that? There is .on('error') anyway.
On 02/15/2012 01:43 AM, Mark Hahn wrote:
Also, I've always wondered why the http request callback didn't follow
the standard signature of (err, data). I wonder if they broke
convention to make the tiny home-page example for PR purposes.
On Tue, Feb 14, 2012 at 3:31 PM, billywhizz <[email protected]
<mailto:[email protected]>> wrote:
wouldn't it be nice if the connection in both the http client and
server were event emitters that emitted the request, close, upgrade
and continue events? would make writing this kind of server, which
seems to be a pretty common pattern, much simpler and more correct
imho.
On Feb 14, 11:53 am, mscdex <[email protected]
<mailto:[email protected]>> wrote:
> On Feb 14, 4:54 am, cong <[email protected]
<mailto:[email protected]>> wrote:
>
> > as we know,multiple get requests can arrive at the same time,
which means there will be mutiple listeners on 'data' event, when
my backend tcp server give a response, multiple get funciton recv
the data at the same time, but I only want the response of their own.
>
> > are there some workaround,all is it true that we can't use one
tcp connection for serving multiple users?
>
> > any help is appreciated
>
> If you really want to do it in parallel instead, you'll probably
need
> to have your tcp backend tag responses using some id that is
unique to
> each connection so that each http request knows if specific incoming
> data is meant for it or another http request. Additionally, you
might
> consider writing a class or function that wraps the tcp stream and
> emits events containing whole incoming messages, to make things a
> little easier. This would allow you to do something like:
>
> // inside http request handler
> streamWrapper.write('foo');
> streamWrapper.once(someUniqueId, .....);
> // or use .on() if you expect more than one message, but remember to
> remove the event handler later on so as to prevent leaking
>
> // inside streamWrapper somewhere after forming a complete incoming
> message
> streamWrapper.emit(uniqueIdFromData, ....);
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
<mailto:[email protected]>
To unsubscribe from this group, send email to
[email protected]
<mailto:nodejs%[email protected]>
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
