|
It's all explained here[^] in this CodeProject article.
The best things in life are not things.
|
|
|
|
|
Short answer: put [Serializable] on the component and make sure that all its fields are themselves serialisable.
|
|
|
|
|
Dear Sir,
Thanks for reply. But this component is not develop by me. this is third party control.
So how can i do that?
Thanks Again
If you can think then I Can.
|
|
|
|
|
Then, if the control does not support serialisation by some easy mechanism (either having [Serializable], implementing ISerializable or providing something like ReadXml/WriteXml methods), you will have to write a wrapper class to serialise all the properties that you can get hold of.
|
|
|
|
|
Hi Can Any One Guide Me How To Encrypt/Redirect The Whole Url In The Address Bar.
Help Me
|
|
|
|
|
You can't encrypt the whole URL. How would the web request know what the endpoint was?
|
|
|
|
|
Hi.
I have a chat site (http://www.pitput.com) that connects user via socket connections.
I have in the client side a flash object that opens a connection to a port in my server.
In the server i have a service that is listening to that port in an async matter.
All is working fine except when i talk to someone after an unknown period of time(about couple of minutes) the server is closing my connection and i get an error in the server :
" A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond".
I dont know how exactly the tcp socket works. does it checking for "live" connection every couple of seconds? how does it decide when to close the connection? Im pretty sure that the close operation is not coming from the client side.
Thanks.
|
|
|
|
|
Wireshark is your friend. Get it started, do your thing, and when you get the error, stop Wireshark and look through the trace. It's probably worth saving the trace then applying an IP filter to see only the traffic of interest. You will be able to see which end failed to respond (and, importantly, the packet that did not get a response).
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Haim Nachum wrote: I dont know how exactly the tcp socket works. does it checking for "live"
connection every couple of seconds?
No.
Haim Nachum wrote: how does it decide when to close the connection? Im pretty sure that the close
operation is not coming from the client side.
The connection is not not closed. You are getting a timeout failure.
Haim Nachum wrote: and i get an error in the server :
You get that error in the server? I would expect that from a client. Clients connect to servers not the other way around.
|
|
|
|
|
TCP operates a timeout if no packets are sent for some time, because this is usually a sign that the connection has been lost. The time varies but is usually around 30s to a couple of minutes. If you want to maintain a connection despite no user interaction, you need to send 'keep-alive' packets or 'pings' every few seconds (one every 20s should be enough) to keep the connection open. However, remember that if you do this, idle connections will never time out and you can run out of server sockets if too many people leave your app open, so you then should have some client code that logs out and closes the socket after a longer inactive time (30 mins or so).
|
|
|
|
|
BobJanova wrote: TCP operates a timeout if no packets are sent for some time, because this is
usually a sign that the connection has been lost.
TCP does not do that.
BobJanova wrote: you want to maintain a connection despite no user interaction, you need to send
'keep-alive' packets or 'pings' every few seconds (one every 20s should be
enough) to keep the connection open
You do that because the server or firewall requires it - not TCP.
BobJanova wrote: However, remember that if you do this, idle connections will never time
out and you can run out of server sockets if too many people leave your app
open, so you then should have some client code that logs out and closes the
socket after a longer inactive time (30 mins or so).
That of course is an architecture problem. If you server is going to respect keep-alives then it must exist in an enterprise that doesn't expect an unlimited number of client all with persistent connections.
One alternative to that possibility is to close even connections that are in use after a given time period. Or require a connect/message/close protocol like http.
|
|
|
|
|
TCP does not do that.
I thought I'd read that, but if it is not TCP, then it is the operating system, because if you open a TCP connection to your own server and send nothing in either direction, at some point it will get closed.
|
|
|
|
|
BobJanova wrote: I thought I'd read that, but if it is not TCP, then it is the operating system,
because if you open a TCP connection to your own server and send nothing in
either direction, at some point it will get closed.
No it won't.
And it isn't the "OS".
OSes have what is typically called a 'IP Stack' which implements IP/TCP/UPD/ICMP.
And they implement it based on the RFCs associated with those protocols.
Application use an API to access that. And assume that the stack implementation is actually correctly implementing the RFCs.
If you are seeing something close connections then it is as I said: the server, the client or something in between like a firewall.
|
|
|
|
|
bob hi, im sorry im not going through the right channels but i am trying to ask you a question in regards to the game lobby,,,,, please contact me at lb4262002@yahoo.co.uk thanks alan (member name TOPLOADER)
|
|
|
|
|
Start a question thread on the article.
|
|
|
|
|
i am sorry i am a new member and am not sure how to start a new thread on the subject, if i could see a new thread tab i would do it sorry. please be patient with me as i have tried to send you a message 3 times and although we are not talking about why i want to speak to you at least i am speaking to you which is a step forward. please can you giude me to the new thread link, many thanks alan.
|
|
|
|
|
Hi,
I am trying to code an application which reads some data from a NetworkStream, saves it into a buffer byte array and then appending it to a file.
Here is the part I am writing the data from the byte array into the file:
FileStream fs = new FileStream(last_save_location, FileMode.Append, FileAccess.Write);
fs.Write(message, 8, bytesRead - 8);
fs.Close();
fs.Dispose();
Everything seems to function fine. I can write the data from NetworkStream to the buffer byte array and then into the file for a while. However, after some time, I get the following error:
The process cannot access the file 'C:\Users\Main\Desktop\test.bin' because it is being used by another process.
I am quite sure that no other process is using the file and that I close the handle each and every time. What do you think the problem is?
Regards,
Can
|
|
|
|
|
The error message is misleading: when it says "... in use by another process..." it may well be, and often is, the same process, not another one. It would better say "... in use by some process...".
Now where within your app is the code you have shown? what threads are involved here? could your code be re-entered, e.g. would there be some Application.DoEvents() calls involved?
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
The code is only called once and it is in a thread. I haven't used the code Application.DoEvents() in any part of the application. I've used Control.CheckForIllegalCrossThreadCalls = false when the form is loaded. Do you think that it has something to do with this?
|
|
|
|
|
SimpleData wrote: I've used Control.CheckForIllegalCrossThreadCalls = false when the form is
loaded
Why?
|
|
|
|
|
I am accessing the GUI elements within a thread that I've created and I didn't want to work with delegates because I didn't think it would constitute a problem in a minor project like this.
|
|
|
|
|
SimpleData wrote: Control.CheckForIllegalCrossThreadCalls = false
don't. It does not solve a problem, all it does is suppressing the exception that has been added in .NET 2.0 for a reason; and it does not remedy all the bad things that are bound to happen. Please read this[^] and fix your code accordingly.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Thanks. I will make the necessary changes.
By the way, in which way can this be causing my problem?
|
|
|
|
|
WinForm Controls aren't thread safe and get accessed quite frequently by the main thread (responding to user actions, repaint messages, etc), so operating them from some other thread as well as from the main thread sooner or later will cause problems.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
It doesn't cause the problem, but it could very well mask the cause of the problem so you won't see it.
Ciao,
luker
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
