I'm currently writing a silverlight game that uses TCP communications. However, it is pseudo-turn based so while I need data pushed to the client, absolutely real-time isn't completely critical.
What would be the advantage of moving to the new (in beta 2) WCF duplex communications? I've already got my server talking TCP, so I don't want to switch unless there are advantages. One thing I was thinking was firewalls. TCP is going to require the
client to open up a port on their firewall to communicate. Could I get around that with WCF duplex?
I'd love to hear more on this new Silverlight communication ability from someone in the know. Thanks!
Duplex communication with a Silverlight 2 Beta 2 client is achieved by having the client poll a destination server for messages within an established session over HTTP.
There will be no TCP connection in Beta 2 for the Duplex Communication on the WCP
Thanks for the docs. I'm still trying to figure out which is a better application for my needs.
Does anyone know the scaling issues that might be seen with a large number of clients? I know the polling is being done intelligently, but I worry about the load that might cause vs just having open TCP sockets. The only reason I'm looking at duplex as
a possibility instead of TCP is that it seems that it would avoid the firewall issue, which is a big win.
Also I have a ton of different messages I need to pass back and forth, so I'm thinking I'll probably need to serialize them down to binary in either case. So TCP is going to send the message a lot more efficiently. But I keep coming back to worrying about
people not being able to use it because of their firewall. People who play stand-alone games are used to opening firewall ports, but I worry that a web user won't be.
I think in your case that it's a no brainer to go straight for WCF Duplex. Here's my rationale:
1. You get the firewall win - that requires no explaining. Your web user isn't going to deal with firewalls. Depending on the type of game it is, the demo might be kids, who may not have access to "Dad's stuff".
2. In terms of scalability, we know that lots of open TCP connections have a finite maximum. I recently produced the Silverlight trailer for the Fox movie "What happens in Vegas" which has a Silverlight 1.0 implementation of Windows Live Messenger. The backing
API for the Messenger API is using Javascript based polling (E-gad!) and it scales fine for a massive user load (the trailer is on Microsoft.com and HUGE amounts of traffic were driven to it). But that's what we would expect - we know that a polling timer
running and polling against an open/close/done behavior is going to scale - the services are edge hosted etc. But then the issue is performance. In the Vegas trailer, the Live API is noticably latent, but not objectionably latent. That's the key - noticable,
but not objectionable. In your case, you've got a turn based scenario in a graphical game, so the difference between noticable and objectionable is going to be a wide berth.
If you add up the pros versus the cons, you've got No Firewall Port + Wide Scaling versus higher performance. That's 2 wins to 1 win. And when you consider that TCP is going to have the finite scaling limit, and that you have to do more work to serialize
and deserialize the message content, you've got even more wins in favor of Duplex.
That's my drive-by 2 cents. My company is about to use it for a chat client, if that makes you feel any better. I would just pull the trigger, but save your TCP bits for sure.
Better yet - abstract the transport at the application level into a plugin pair - one for the client and one for the server - keep your TCP bits on server and client and only deal with string typed objects. Then you can build another pair for WCF duplexing
and hotswap the whole rig. That's what I would do.
With the WCF duplexing will I be able to detect if a client has dropped? The server needs to know that the client is still connected. I guess it could just see that it hasn't polled recently?
I've already got the entire TCP/IP layer written including custom serialization classes so I hate to go back and start all over again. I just know the firewall thing is going to end up killing us.
Jamie H
Member
123 Points
90 Posts
WCF duplex communications vs TCP
Jun 08, 2008 01:41 AM | LINK
I'm currently writing a silverlight game that uses TCP communications. However, it is pseudo-turn based so while I need data pushed to the client, absolutely real-time isn't completely critical.
What would be the advantage of moving to the new (in beta 2) WCF duplex communications? I've already got my server talking TCP, so I don't want to switch unless there are advantages. One thing I was thinking was firewalls. TCP is going to require the client to open up a port on their firewall to communicate. Could I get around that with WCF duplex?
I'd love to hear more on this new Silverlight communication ability from someone in the know. Thanks!
Jamie
beta 2 WCF duplex TCP
SteveWong
Contributor
6719 Points
1346 Posts
Re: WCF duplex communications vs TCP
Jun 08, 2008 06:04 AM | LINK
Duplex communication with a Silverlight 2 Beta 2 client is achieved by having the client poll a destination server for messages within an established session over HTTP.
There will be no TCP connection in Beta 2 for the Duplex Communication on the WCP
It is a good new for you i think.
SteveWong (HongKong)
Please mark post as answer if they help you
Jamie H
Member
123 Points
90 Posts
Re: WCF duplex communications vs TCP
Jun 08, 2008 06:15 AM | LINK
SteveWong
Contributor
6719 Points
1346 Posts
Re: Re: WCF duplex communications vs TCP
Jun 08, 2008 08:12 AM | LINK
it depends on how much data you have to get
if it is just a little bit such as only getting the score and the ranking place of the player
it is so simple to do with the socket
SteveWong (HongKong)
Please mark post as answer if they help you
jacle169
Member
19 Points
28 Posts
Re: Re: WCF duplex communications vs TCP
Jun 08, 2008 04:58 PM | LINK
Hi Steve!
How can I get the silverlight beta2 duplex communications samples!?
Thanks!
duplex
SteveWong
Contributor
6719 Points
1346 Posts
Re: Re: WCF duplex communications vs TCP
Jun 08, 2008 05:19 PM | LINK
I found it from the documentation but I dont know if you have it or not. I just paste it here
http://msdn.microsoft.com/en-us/library/cc645028(VS.95).aspx
SteveWong (HongKong)
Please mark post as answer if they help you
Jamie H
Member
123 Points
90 Posts
Re: Re: WCF duplex communications vs TCP
Jun 08, 2008 07:22 PM | LINK
Thanks for the docs. I'm still trying to figure out which is a better application for my needs.
Does anyone know the scaling issues that might be seen with a large number of clients? I know the polling is being done intelligently, but I worry about the load that might cause vs just having open TCP sockets. The only reason I'm looking at duplex as a possibility instead of TCP is that it seems that it would avoid the firewall issue, which is a big win.
Also I have a ton of different messages I need to pass back and forth, so I'm thinking I'll probably need to serialize them down to binary in either case. So TCP is going to send the message a lot more efficiently. But I keep coming back to worrying about people not being able to use it because of their firewall. People who play stand-alone games are used to opening firewall ports, but I worry that a web user won't be.
RodKestler
Member
30 Points
10 Posts
Re: Re: WCF duplex communications vs TCP
Jun 21, 2008 12:08 AM | LINK
Jamie:
I think in your case that it's a no brainer to go straight for WCF Duplex. Here's my rationale:
1. You get the firewall win - that requires no explaining. Your web user isn't going to deal with firewalls. Depending on the type of game it is, the demo might be kids, who may not have access to "Dad's stuff".
2. In terms of scalability, we know that lots of open TCP connections have a finite maximum. I recently produced the Silverlight trailer for the Fox movie "What happens in Vegas" which has a Silverlight 1.0 implementation of Windows Live Messenger. The backing API for the Messenger API is using Javascript based polling (E-gad!) and it scales fine for a massive user load (the trailer is on Microsoft.com and HUGE amounts of traffic were driven to it). But that's what we would expect - we know that a polling timer running and polling against an open/close/done behavior is going to scale - the services are edge hosted etc. But then the issue is performance. In the Vegas trailer, the Live API is noticably latent, but not objectionably latent. That's the key - noticable, but not objectionable. In your case, you've got a turn based scenario in a graphical game, so the difference between noticable and objectionable is going to be a wide berth.
If you add up the pros versus the cons, you've got No Firewall Port + Wide Scaling versus higher performance. That's 2 wins to 1 win. And when you consider that TCP is going to have the finite scaling limit, and that you have to do more work to serialize and deserialize the message content, you've got even more wins in favor of Duplex.
That's my drive-by 2 cents. My company is about to use it for a chat client, if that makes you feel any better. I would just pull the trigger, but save your TCP bits for sure.
CTO, Hatch Innovations, LLC
RodKestler
Member
30 Points
10 Posts
Re: Re: WCF duplex communications vs TCP
Jun 21, 2008 12:10 AM | LINK
Jamie:
Better yet - abstract the transport at the application level into a plugin pair - one for the client and one for the server - keep your TCP bits on server and client and only deal with string typed objects. Then you can build another pair for WCF duplexing and hotswap the whole rig. That's what I would do.
CTO, Hatch Innovations, LLC
Jamie H
Member
123 Points
90 Posts
Re: Re: WCF duplex communications vs TCP
Jun 21, 2008 05:36 PM | LINK
Interesting.
With the WCF duplexing will I be able to detect if a client has dropped? The server needs to know that the client is still connected. I guess it could just see that it hasn't polled recently?
I've already got the entire TCP/IP layer written including custom serialization classes so I hate to go back and start all over again. I just know the firewall thing is going to end up killing us.