|
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-----
|
|
|
|
|
ok, i guess i see how this is done-- pls correct me if i'm wrong: on invoking Formatter.Serialize, Formatter uses reflection to check whether ISerializable is implemented in the class of the object. if so it calls the interface. If not it uses reflection to serialize all the fields, checking for the NonSerialized as it goes.
is that what happens? and if this is, how is that done efficiently enough to not take forever to serialize each two-bit-- i mean two-byte-- object in the graph? does BinaryFormatter perform some sort of run time analysis or "compilation" like regex?
________________________________________
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!
|
|
|
|
|
You should read Serializing Objects[^] in the .NET Framework. I think it'll help understand many of these concepts.
As far as performance, it is true that reflecting all those fields and Types takes a while but it is necessary when crossing contexts (via Remoting) or serialing to streams for any other means. The process of serialization is actually pretty complex. If you're interested in the details, you should use ildasm.exe (if you know IL) or a good decompiler like .NET Reflector[^] to see how much of that is done.
Our application I designed uses A LOT of Remoting in the Internet-deployed edition and it functions pretty fast - not much slower than the LAN version (and most people don't even notice). As far as I can tell, nothing is cached from serialization to serialization either because everything changes from call to call.
-----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, yes i also use BinaryFormatter on pretty big objects and it seems remarkably efficient. Thanks for the suggestion on Reflector (do i also need to learn il?).
Thanks for the insights and the Reflector fishing rod!! 
________________________________________
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!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
