Web services

[NickFitz]

Thanks. Actually it's pretty much going to be one client most of the time. So it probably would keep up, but constantly polling still seems a bad idea (though I guess I could make that a fallback mode).

Now if only Flash's security sandbox would work the way the instructions say it works...

One client shouldn't be a problem, although I still don't think it's likely to be necessary to poll any more often than ten times a second max, given human reaction times - unless it's a cool game requiring quick reflexes

Can't really help with Flash I'm afraid

One thing that helps a lot when dealing with HTTP is a client-side HTTP debugger - you can get a better idea of what's actually happening on the wire (e.g. what HTTP response codes you're getting).

Fiddler, written by a chap at Microsoft, is a free download - Windows only.

Charles has a trial version that runs (with occasional nag screens) for thirty minutes, and is cross-platform - it can also do some rather neat tricks that probably aren't relevant to your problem.

[VectraMan]

Thanks. Actually it's pretty much going to be one client most of the time. So it probably would keep up, but constantly polling still seems a bad idea (though I guess I could make that a fallback mode).

Now if only Flash's security sandbox would work the way the instructions say it works...

[VectraMan]

Ta. .NET isn't an option, and correct me if I'm wrong but it looks like remoting is .NET's (much improved) take on DCOM.

Looks like I was barking up the wrong tree. Binary data over sockets is back within my area of expertise, so in some ways it's a relief to know web services won't do what I want. I was just trying to do The Right Thing by using all this webby soapy stuff everybody keeps talking about.

[phayes]

web services are stateless, you cannot keep a port open.

really look into remoting as it is web services for the lan, if you can allow port 80, then you should be fine.

http://www.developer.com/net/cplus/article.php/1479761

whatever you do i hope you solve it. :-)

[Jaws]

Web services follow the http protocol so therefore the connection can not be kept open as you are describing. Not idle anyway, as a timeout is likely to occur. You may be able to make the response object continuously send data towards the client, although in my opinion a client to server polling option would be better and probably require less in bandwidth than leaving the response stream running indefinitely.

[VectraMan]

if you're using a LAN, why are you using HTTP, look at using Remoting over TCP/IP, the binary traffic is much faster and you can manage the channels you want to open etc.

Well it isn't necessarily a LAN, and as I understand it the attraction of HTTP is that it then gets round issues of firewalls and proxies etc. which any kind of direct connection does not.

[phayes]

if your using a LAN, why are you using HTTP, look at using Remoting over TCP/IP, the binary traffic is much faster and you can manage the channels you want to open etc.

[VectraMan]

This isn't my area of expertise, so be gentle.

As I understand it, a client (in this case a flash movie, but that won't be the only use) can open an HTTP connection in the background, send XML and get XML back from something on a server. Fine.

Can this connection be kept open? If I want something reporting live data from the server, can the server just keep sending data down the same connection, or does the client have to keep polling, establishing a new connection with each poll?

And if it does need to keep polling with a new connection each time, is it reasonable to do that say 20 times a second over a LAN?

Ta.