|
I did but to me it looked more like remoting is used to offload processing to another computer.
What I want are persistent connections for a couple hundred clients, constantly pushing or pulling data.
So, this will be very performance critical.
What are the other possibilities to approach this type of application?
However, I'll have a deeper look at remoting and see whether it suits my needs
|
|
|
|
|
Try webservices, but webservices will work for pulling data, as you know it works using a web server, and the web server can't send information to the clients, unless the client ask for the information.
I used remoting to push and pull info from the server and the clients.
Free your mind...
|
|
|
|
|
That's the reason why I can't use web services as the data hast to be pushed to the client.
What about developing an own TCP/IP Server... do you see any benefit in doing this?
|
|
|
|
|
This was already discussed elsewhere I think. I'll give you some advice: don't develop a server which handles each client in a separate thread, cause that will cause processor overloading with >20 clients.
Maybe you'll find the answer at .NET 247 
greetz
*Niels Penneman*
Software/Dev Site
Personal Site
|
|
|
|
|
hm but every client will receive different data concurrently. How else could this be accomplished without threads?
|
|
|
|
|
Sorry, it does require multiple threads, but make sure you are not running 200 threads at once, you'll have to pool / manage your threads... But that's something I - too (i guess) - am not familiar with.
greetz
*Niels Penneman*
Software/Dev Site
Personal Site
|
|
|
|
|
Why invent the wheel when you already have rockets going to mars ???
That's up to you, but remoting is very robust.
Any way, if you need an example, I can send you some code.
Free your mind...
|
|
|
|
|
I agree with the first reply that .NET Remoting is worth looking into, but there is another, easier alternative.
You can use XML Web Services over HTTPS (HTTP over SSL) if your server has a valid certificate. If you're developing an internal application and have ActiveDirectory, you (or IT) can use the Certificate Services to create a Web Server certificate and install it in IIS. For external applications, I recommend getting an SSL cert from VeriSign, Thawte, or any other certificate authorities (CAs). Then, just make sure you use a URL to access your Web Servce using the https scheme instead of http. It is automatically encrypted without you having to do anything.
If you do look into .NET Remoting - which is far more robust, though WS Security is certainly providing additional features for Web Services - I recommend a good book for both new and intermediate Remoting developers from Microsoft Press, ".NET Remoting" by McLean, Naftel, and Williams: http://www.microsoft.com/mspress/books/6172.asp[^]. You could use channel sinks to encrypt, compress, route, or anything else to the messages in an abstract manner. This book cover that and even includes an example channel sink and derivative RealProxy for doing basic load balancing. It's a good book!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
thanks for both your replies. I'll definitely have a deeper look at remoting.
Unfortunately I can not use XML Web Services as i have to push date from the server to the client.
|
|
|
|
|
You want this book as reffed in this thread, it shows an implementation of an encrytion sink for remoting in Chapter 9.
Remoting does seem to be your answer.
DTrent
|
|
|
|
|
The snippet below seems to me to reek of inelegance, yet i have no better solution. i can't manage with using {} because the pictureBox barfs if i dispose the image too soon.
Is there a better way??
Image disposeOfSoon = pictureBox.Image;
pictureBox.Image = newImage;
if (disposeOfSoon != null) disposeOfSoon.Dispose ();
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
Image disposeOfSoon = pictureBox.Image;<br />
using (disposeOfSoon)<br />
{<br />
pictureBox.Image = newImage; <br />
}
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
I'm not sure if that works, but if it does, its totally ludicrous!!!
1. IMO the variable shouldnt leave the using block.
2. No object was created, only referenced.
leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
I have to be honest that I could not see the point myself with the original code. So I guessed its not real and just an example.
in terms of your points:
1. the variable does not leave the using block...
2. calling dispose on an object which is pointing at a image works, as all you are doing is asking the image object to call dispose - which is worth doing if you don't want it anymore.
hope this makes sense, or else I've misunderstood your points 
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
The code is real, it describes a common situation: a picture box displays an image for some unspecified duration, then in response to some event the image should change. AFAIK this requires the soon-to-be-old current image be pointed to, the new image be displayed, and the now-old-current image be disposed. Surely this is a common problem. Nes pas?
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
Philip Fitzsimons wrote:
the variable does not leave the using block...
What I meant to say was the variable was enclosed, iow declared too. Thus the compiler can pickup a problem readily.
Philip Fitzsimons wrote:
calling dispose on an object which is pointing at a image works, as all you are doing is asking the image object to call dispose - which is worth doing if you don't want it anymore.
Its all and well, but not if it someone elses object that mite need to exist after the method returns. Refer to above. IMO the object should be sandboxed in the scope.
leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
i agree in principle with what you're saying, that's why i wrote the post. the problem is that there isn't any good local "scope" for the image, once the pictureBox gets it it should belong to the pictureBox. perhaps i should write PictureBoxEx.. (yecch!!)
btw the snippet provided by Philip Fitzsimons "looks" kinda wierd but works great! if we could get EricGu to rename the keyword "using" to "noLongerUsing" the snippet would read:
Image tmp;
noLongerUsing (tmp = pictureBox.Image)
{pictureBox.Image = aBrandNewImage;}
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
 what are the design tradeoffs between different constructs to collect objects based on some common functionality?
Suppose i want to rely on objects being able to "display" themselves. What's the difference between using Abstract Base, Interface, or Attribute? Since c# doesnt allow multiple inheritance i'd guess Abstract base should be reserved for "core" properties of the object, and i guess Interfaces are there exactly so my displayThyself methods can be expressed. What about [Serializable], that has properties similar to an interface except for specifying a constructor as one of the mandatory methods.
Is there a discussion of what construct to use when and why?
Thanks in advance!
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
TuringTest1 wrote:
i'd guess Abstract base should be reserved for "core" properties of the object
Yes.
TuringTest1 wrote:
i guess Interfaces are there exactly so my displayThyself methods can be expressed.
Well,you mention that multiple inheritance is not allowed in C#,with Interfaces you can have multiple inheritane,you inherit a class from another class AND how many interface you want.
Serializable word express itself.It means you can seriallize this class. MSDN exapain these things very good,you can start from it.
Mazy
No sig. available now.
|
|
|
|
|
Mazdak wrote:
Serializable word express itself.It means you can seriallize this class. MSDN exapain these things very good,you can start from it.
yes, [Serializable] is implemented as an attribute, but it really looks like an Interface, doesn't it? except that for technical reasons (one of the 2 interface "methods" is a constructor) it can't be an interface. Or something like that. What are the similarities and differences between something implemented as an Interface and something like [Serializable] which is implemented via attributes?
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
Actually, if you attribute your class with the SerializableAttribute, the default serialization will serialize public and private fields of your class. There is an interface, ISerializable, that allows you to control the serialization so that you, the developer, controls what gets serialized and what doesn't. This does go along - like the original poster mentioned - with a constructor that has the signature (SerializationInfo, StreamingContext). This constructor can have any access modifier, but are common protected so that subclasses can pass serialization info to its base class.
There are also other serialization interfaces that can be useful, such as the IDeserializationCallback that allows you to perform any layout or hook-ups after serialization is complete, and the ISerializationSurrogate that - with an IFormatter implementation allows you to serialize Types that are themselves serializable. You can also use a SerializationBinder with the formatter to serialize from one Type to another, using SerializationBinder.BindToType. This seems especially handy when you have to upgrade a serialized file with older versions of Types.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
So marking class Foo with [Serializable] magically adds expands Foo by implemnting the 2 ISerializable methods ending up with Foo : ISerializable?
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
No, you still have to implement ISerializable if you wish. Just attributing the class as I mentioned before with SerializableAttribute serializes all private and public fields. Implementing ISerializable is required if you want to control what gets serialized. See the ISerializable documentation for both more detail and an example.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Heath Stewart wrote:
Actually, if you attribute your class with the SerializableAttribute, the default serialization will serialize public and private fields of your class.
how does this happen? doesnt it require "somebody" to implement a default ISerializable for the class? or is it just done at runtime via reflection? [[need more smiley flavors for "huh??"!!!)
________________________________________
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
|
|
|
|
|
If you'll read the documentation for SerializableAttribute, you'll see that the serialization infrastructure serializes private and public fields by default if a class is attributed (the class itself - inheriting the attribute doesn't make a derivative class serializable). This is done via reflection, yes. Note that your class must be attributed with the SerializableAttribute even if it implements ISerializable to be serializable. Implementing the interface just gives you explicit control over serialization of your Type.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
