VB.NET - Client Server Application - Asked By Ali Valji on 03-Feb-03 09:59 AM

Having read a networking article by Peter Bromberg I was wondering how you 
would go about developing an application that returns information to all 
clients when a single client changes data. Take the example of an auction site, 
if a single person changes the price on an item how would you go about 
reflecting these changes to all those who are currently viewing that particular 

Currently I have implement a version of the above mentioned example using ASP, 
JavaScript, Remote Scripting. This is expensive because I have set a refresh 
rate of 20 seconds. What I'd want to do preferably in .net is a client server 
application, however I can see potential problems with Firewalls, am I right in 
thinking this?

Any suggestion as to how I should approach this task would be appreciated 

Number of different approaches - Asked By Peter Bromberg on 03-Feb-03 11:06 AM

to this situation. What immediately comes to mind
is a multicast sockets setup where the server broadcasts
the change(s) to all clients.

If you have a problem with firewalls, then you probably want
to use a webservice that clients would refresh to on a timed
basis, much like you describe in your current application.

Another angle would be to look into hosting a remoting server
and have each client be a "subscriber" but that's beyond the
scope of forum posts.

Further thoughts on publishing changes - Asked By Chris Falter on 25-Jul-14 01:21 AM

I like Peter's idea of using .NET remoting.  You could have each client pass a reference to a delegate to the server.  The server would add each reference to its event (internally, it's a linked list).  When a change takes place, the server fires the event, and all the delegates get called.

A couple of issues:
* firewall: you can configure .NET remoting to use an arbitrary port.  This would allow an admin to open an arbitrary port on the firewall.  This is far superior to DCOM, which requires that an admin open specific ports which leave gaping holes in security infrastructure.

* timeout/error handling: the server will call each delegate in turn when the event is fired.  Be sure to use exception-handling to prevent conditions on one machine from stopping the propagation of the event to all delegates.  Also, configure a short-enough timeout on the remoting connections so that temporary problems in one network segment do not prevent the traversal of the delegate list by the server.
Asked By Ali Valji on 05-Feb-03 04:42 AM
Does anyone know much about pushlets?