New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question - return response data from server on client publish #390
Comments
You can't return anything from an event listener; it will be ignored by the server. The way to 'respond' to a published message is to publish your own message, on a channel the original sender is subscribed to. Or, just make a regular HTTP request if all you want is a request/response semantic. |
thank you for reply, I don't want use xhr requests because they are slow on our server which means unusable for my application... that's why i'm trying to replace them with websockets. Sometimes I need to wait for data from server... I tried create temporary channel for response but I couldn't figure out how to wait for message on this channel. |
I'm not sure what you mean by "how to wait for message on this channel" -- could you explain what you're trying to do in more detail? |
One up for this request. Our message server (java/cometd) implementation supports rooms which we can join by publishing a message on the " /service/room/join" service channel, containing the room id.
Unfortunaltely the promise of a subscribe operation shows the same behaviour. The response from the serve ris not passed to the resolved promise:
|
I'm having the same problem @RonB... No idea why you can't do this... The data is even sent down to the client, it's just not passed into the promise. I will have to fork the project and fix this... |
@shawn-simon I'd be glad to help out if you want |
@RonB Ah thanks! But I wound up going with socket.io after trying it out. The API fits my application a bit better. |
I assumed Faye would solve this as well. @jcoglan Faye docs say "Faye is based on the Bayeux protocol, and is compatible with the reference implementation of Bayeux provided by the cometD project." Bayeux spec from cometD says that /service/** should be usable for request/response purpose: http://docs.cometd.org/reference/bayeux_service_channel_operation.html I don't see code in the Faye repo for handling req/resp to service channels. Is this a supported feature, or are patches needed to support this? |
@House-MD said:
@RonB said:
These comments touch on part of why the The spec says that the server may respond to a published message with a publish event acknowledgement containing the fields This is not a new message with its own application data; it has no Given this, it's not clear how a server should respond to a message published by a client. Should it include a It's also not clear that 'response' means one message. Given pub/sub semantics it's possible for any peer to send many or no logical responses to some message it receives. If the server is allowed to respond many or no times, then a promise is not a good model for this response; it makes more sense as an event listener or stream. Finally it's not clear that the server must respond immediately. Say a client publishes to a channel and it takes the server a very long time to compose a response, say, a time longer than the client's connection timeout. Should this delay the sending of the acknowledgement? If the Faye client doesn't receive timely confirmation of a published message, it will retry it. If we need to wait a long time to create the Because of the above, when I have wanted any semantics where one peer Alice (including the server) needs to 'respond' to another Bob, I have had Alice publish messages to some channel Bob is subscribed to. It allows for zero or multiple responses, and responses that take a long time, and doesn't rely on non-standard fields being added to protocol messages. Even if we ignore all the above and constrain {
"id": "1",
"channel": "/foo",
"successful": false,
"error": "405:/foo:Invalid channel"
} Then the promise is rejected with an error object with the fields: {
code: 405,
params: ['/foo'],
message: 'Invalid channel'
} This is the parsed For reasons given in #385 and #400 and elsewhere (and the above comments are relevant to #407 which I've not got to yet) the promises returned by |
@RonB said:
Could you clarify why it's done this way? Presumably to join a room, a client also needs to subscribe to a channel. How does it do that; does it subscribe itself or does the server subscribe it on receipt of the If the client has to do all this in multiple steps there's a greater chance of race conditions that cause the client to miss messages between requesting the room details and subscribing for updates. |
Did anyone have any feedback on my comments and questions above? |
All good points. I think specs have their place, and are great for galvanizing the development of clients for a common purpose. However, when the spec falls short, the implementation should take liberties. For example, I think its fine that a published event (i.e. "request") on the When dealing with requests that don't have an immediate outcome, I just had the server publish events on the channels. In these "slow response" cases, I consider the request to be saying to the server "do something eventually" and the response to that request to be "yes, I'll considering doing something eventually" and relying on my inbound extensions to handle the rest. Regarding joining channels versus having presence in a room, the two have different use cases. A channel is used for scoping the broadcast of messages to particular a subscriber set. Presence in a room is slightly different, in that my request to receive messages on a channel doesn't necessary imply that I wish to be known as present to all other clients. Is see the two as potentially over-lapping domains, but not 1:1. I ended up writing a session extension and presence extension that maps clientIds and session tokens (users) and what I call "spaces" together. It was quite difficult tracking client connections / disconnections. For example, I noticed that clients that disconnect without broadcasting disconnect are are silently dropped from channels without an outbound disconnect message. So in fact, using channels for presence isn't obvious nor is the spec clear about how to handle client timeouts due to disconnection. |
Sorry I've not got back to this issue in a while. I'm now catching up before shipping 1.2.0. For reasons I gave in #400, I'm not going to add support for the Regarding yielding
This is a fair point but I want to know what other servers actually do. Faye does not return a Do other servers return |
Hello,
I'm trying create websocket api for my new project but i cannot solve one thing.
Basic communication is working well (publish/subscribe). But I need in some times on publish to specific channel return response with data to user while user is waiting for those data.
for client side I found:
var resp = client.publish('/channel',data);
resp.then(function() {
alert('Message received by server!');
}, function(error) {
alert('There was a problem: ' + error.message);
});
but I cannot figure out how to pass data from node.js server to this response...
I will need something like this:
fayeAdapter.on('publish', function(clientId,channel,data){
if(channel == 0)
return {data:'some data'};
});
and then at client this
resp.then(function(data) {
alert(data);
}, function(error) {
alert('There was a problem: ' + error.message);
});
Thank you and have a nice day.
The text was updated successfully, but these errors were encountered: