A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'm at the design stage of working with a client-server application using XML sockets. I'm quite new to client-server issues in general, and I'm trying to lay the groundwork such that I won't regret things later (if concurrent users and amount/frequency of traffic is nontrivial).
It would be simplest for me to make the client simply wing out an update whenever it has one, and the server to do the same, but something about this sets off my "no free lunch" detector. So what I want to ask is, are there low-level things I should be aware of in planning how this communication will take place?
For example, suppose that different parts of my client may independently send messages to the server at nearly the same time. Is there a value in queueing these up and marshalling them, as opposed to sending several different updates near-simultaneously? (Assuming the overall size is the same.) For another example, would it be a useful thing to do for each side to queue up outgoing messages during the time an incoming message is being received, as opposed to sending out updates while the socket is receiving data?
I don't know enough to know if those two examples particularly are relevant. So what I mean to ask about is issues of that general nature.
Side note: the client will be using the flash player, which in general piggybacks all its network operations onto the browser. So if there are issues like these, but modern browsers handle them for me, then it might be that I don't need to worry.
If anyone has any thoughts, or even better knows of relevant articles to point me at, I'd be indebted.
Tuesday, July 24, 2007
Er, what the hell is an "XML socket" anyway?? Do you mean "transferring XML data over a network" or is there some magical "socket" that somehow applies to files containing data and meta-data that happen to be presented as text?
Thursday, July 26, 2007
Well, I mean the client makes a persistent socket connection with the server that's used to exchange fragments of XML. In this case the Flash player has APIs particularly for socket connections devoted to XML, and the server does likewise. But my assumption is that it's the browser that actually makes the connection, and I have no idea whether the browser knows what kind of data is going back and forth.
Whether this setup differs in any important ways from binary socket connections that happen only to be transmitting text is something I don't know a lot about, but it may be that it does not.
At any rate moving XML through sockets is the usual way to approach persistent connections in Flash, so I supposed the same might be true in AJAX or other platforms, but now that I look that seems not to be the case. Sorry if I sounded obtuse; like I said I'm quite new to this.
Friday, July 27, 2007
An XMLSocket is a Flash-specific construct for creating a persistent connection between Flash and a server through which XML s passed.
You are right to be leary of small bugs and browser incompatibilities coming back to bite you later. To mitigate the risk, you may want to look at the commercial socket servers that are designed to work with Flash (Google "flash socket server"). They have likely sorted these issues out and will definitely have a support department and user community that can assist if you run into trouble.
Monday, July 30, 2007
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz