Skip to content
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

Create example for parallel server #131

Merged
merged 8 commits into from
Jun 30, 2017
Merged

Create example for parallel server #131

merged 8 commits into from
Jun 30, 2017

Conversation

janhohenheim
Copy link
Contributor

This server sends and receives messages independently

This server sends and receives messages independently
@daboross
Copy link

daboross commented Jun 13, 2017

Could you add futures-cpupool as a dev-dependency in Cargo.toml? I don't think it'll compile/test the example without it.

@janhohenheim
Copy link
Contributor Author

janhohenheim commented Jun 14, 2017

Thanks for the reminder.
I'm brewing up a better example anyways so people can use it as a scalable start point. Gonna fix the travis build when that is ready.

@illegalprime
Copy link
Collaborator

Hey this is awesome! Thanks a bunch, travis was being weird but now it's fixed. Feel free to rebase on top of the latest changes.

@janhohenheim
Copy link
Contributor Author

janhohenheim commented Jun 29, 2017

Hmm, any idea why my cargo fmt with your .rustfmt.toml is generating a different output than Travis?

Edit: I see, you're running an old version of rustfmt. I'm gonna downgrade my local installation then. Maybe in the future you should look into https://github.com/nabijaczleweli/cargo-update. With it you can cache your rustfmt on Travis and let it auto update as needed :)

@janhohenheim
Copy link
Contributor Author

Feel free to merge it now. I wrote this example with a game server in mind.

As I am not that experienced in working with futures, I most probably made some things way more complicated that they could be. But hey, it's parallel and scalable to as many users as you like :)

@janhohenheim
Copy link
Contributor Author

I think Travis bugged out there.
For me it says right here that the build is still running
image
While on the actual build page it says it finished 24 ago
image

@illegalprime illegalprime merged commit 7bd2def into websockets-rs:master Jun 30, 2017
@illegalprime
Copy link
Collaborator

Thank you again!

@chmnchiang
Copy link

Regarding the code in this example:

send_channel_in.for_each(move |(id, msg): (Id, String)| {
	let connections = connections.clone();
	let sink = connections.write()
	                      .unwrap()
	                      .remove(&id)
	                      .expect("Tried to send to invalid client id",);

	println!("Sending message '{}' to id {}", msg, id);
	let f = sink.send(OwnedMessage::Text(msg))
	            .and_then(move |sink| {
		                      connections.write().unwrap().insert(id, sink);
		                      Ok(())
		                     });
	remote.spawn(move |_| f.map_err(|_| ()));
	Ok(())
})
.map_err(|_| ())

Isn't it possible that the last message haven't been sent completely but the send_channel_in receive another message to the same client? The sink of the client would be removed from the hashmap temporary then.

@janhohenheim
Copy link
Contributor Author

Good catch, I think you're right. Unfortunately I don't have time right now to fix it. Do you wanna give it a try?

@chmnchiang
Copy link

chmnchiang commented Oct 25, 2017

I've create the pull request #148, but since I'm a newbee to tokio and future, maybe you could check whether my fix is correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants