|
So I've got a client server application going (again) and I've run into a little problem.
So far the server side sits idly waiting for a connection, eventualy it will receive a connection from the client. After a period of time T the server will close the connection with the client if there is no activity (incase for some reason the client didn't disconnect as it should).
After closing the connection it waits again for a new connection. But, if the client that was previously connected tries to send data, then the server side picks this up as an incomming connection and trys to accept it, where I then get the exception becuase that line was already closed. 
So what am i to do?
My current favourite word is: I'm starting to run out of fav. words!
-SK Genius
Game Programming articles start - here[ ^]-
|
|
|
|
|
SK Genius wrote: After a period of time T the server will close the connection
How?
SK Genius wrote: After closing the connection it waits again for a new connection
How?
SK Genius wrote: So what am i to do?
Post useful information if you expect someone to be able to help you.
led mike
|
|
|
|
|
led mike wrote: After a period of time T the server will close the connection
How?
Calling .Close on the stream and .Stop() on the TcpListener.
led mike wrote: After closing the connection it waits again for a new connection
How?
Starting the TcpListener and calling BeginAcceptSocket
My current favourite word is: I'm starting to run out of fav. words!
-SK Genius
Game Programming articles start - here[ ^]-
|
|
|
|
|
So an exception is thrown in your async accept handler? When? Can't you catch the exception? Are you a software developer? What experience do you have with Socket programming?
led mike
|
|
|
|
|
I can catch and ignore the exception then wait for another connection. I just figured there was something better that i could do, y'know to solve the problem rather than just cover it up.
As for experience with sockets, not so much, same as alot of other stuff though I suppose.
My current favourite word is: I'm starting to run out of fav. words!
-SK Genius
Game Programming articles start - here[ ^]-
|
|
|
|
|
SK Genius wrote: I just figured there was something better
Ok. I re-read the thread:
SK Genius wrote: Calling .Close on the stream and .Stop() on the TcpListener.
That doesn't seem correct. You should call TcpClient.Close(), and there is no reason to stop() the listener. It sounds like you may have some fundamental errors in your coding of this application.
led mike
|
|
|
|
|
There is no TcpClient, I'm just using a NetworkStream obtained from the socket.
And even if I don't close the stream or stop the listener, I still get the error. I'm quite unsure of what object has actually been disposed.
If i keep hold of the socket and call Disconnect(true) to re-use the socket, it hangs (probably until it times out). If i call Disconnect(false) it closes whatever it closes and I still get the error.
My current favourite word is: I'm starting to run out of fav. words!
-SK Genius
Game Programming articles start - here[ ^]-
|
|
|
|
|
hey
i duno if this will help but i adapted the code of this Client Server[^] for the app im developing...
i have no conection issues, even if i terminate the proccess on the client or shut the client pc down (hard) the server disconects the client correctly...
i had some handle issues with it tho, if i remembered corectly it was a Invoke call that was trying to access a not yet created windows handle, but that was easaly fixed and my server has been running 2 months non stop with no issues
Harvey Saayman - South Africa
Junior Developer
.Net, C#, SQL
you.suck = (you.passion != Programming)
|
|
|
|
|
I can already do that, the problem i have is that in the unlikely event that the client doesn't respond for a certain amount of time and the server closes the connection, yet the client is still actually running. In this case the client thinks it has a connection to the server, when it actually doesn't.
It's unlikely that this will happen, but I need to be sure.
My current favourite word is: I'm starting to run out of fav. words!
-SK Genius
Game Programming articles start - here[ ^]-
|
|
|
|
|
well... my server kills the client if i close the connection from the server... or terminate the server process for that matter
Harvey Saayman - South Africa
Junior Developer
.Net, C#, SQL
you.suck = (you.passion != Programming)
|
|
|
|
|
ill even send you the code for mine if you want 
the only thing is that "messages" are broadcasted to all clients... duno if thats acceptable for what your doing...
Harvey Saayman - South Africa
Junior Developer
.Net, C#, SQL
you.suck = (you.passion != Programming)
|
|
|
|
|
Apparently it all works out if i just ignore the error, and let the client time-out when it tries to send/receive data. It just doesn't seem right though...
My current favourite word is: I'm starting to run out of fav. words!
-SK Genius
Game Programming articles start - here[ ^]-
|
|
|
|
|
On the server side, I call BeginRead to wait for data - but I forgot to call EndRead. After adding that in i now get the expected IOException because the connection was closed, rather than the AcceptSocket method picking up... something.
My current favourite word is: I'm starting to run out of fav. words!
-SK Genius
Game Programming articles start - here[ ^]-
|
|
|
|
|
Is there any way to let my application know when the status of a Service has changed?
Or whenever theres a new entry in the Event Log?
Thx
|
|
|
|
|
|
|
I'm seeing a debug assertion failure in our code that makes me question how much I know about atomicity. Should this Debug.Assert ever fail?
private object syncObject = new object();
private bool isWorking;
void Foo()
{
lock (syncObject)
{
if (!isWorking)
{
isWorking = true;
new Action(DoSomething).BeginInvoke(OnDoSomethingCompletedAsync, null);
}
}
}
void DoSomething() { }
void OnDoSomethingCompletedAsync(IAsyncResult result)
{
lock (syncObject)
{
Debug.Assert(isWorking);
isWorking = false;
}
}Should this ever happen? I can say for certain that these are the only 2 functions I read or write to the isWorking field. Any idea what's going on?
Life, family, faith: Give me a visit.
From my latest post: "A lot of Christians struggle, perhaps at a subconscious level, about the phrase "God of Israel". After all, Israel's God is the God of Judaism, is He not? And the God of Christianity is not the God of Judaism, right?"
Judah Himango
|
|
|
|
|
Maybe you are calling Foo twice (Double click scenario) on the same object. Move OnDoSomethingCompletedAsync to an anon method and move isWorking inside of Foo and see what happens.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
Foo gets called many times, over and over again. But that shouldn't matter, right?
Life, family, faith: Give me a visit.
From my latest post: "A lot of Christians struggle, perhaps at a subconscious level, about the phrase "God of Israel". After all, Israel's God is the God of Judaism, is He not? And the God of Christianity is not the God of Judaism, right?"
Judah Himango
|
|
|
|
|
It can and it does. That's just the way it goes, I suppose.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
It can matter? Can you elaborate?
It doesn't seem like it should matter since it does nothing when isWorking == false
Life, family, faith: Give me a visit.
From my latest post: "A lot of Christians struggle, perhaps at a subconscious level, about the phrase "God of Israel". After all, Israel's God is the God of Judaism, is He not? And the God of Christianity is not the God of Judaism, right?"
Judah Himango
|
|
|
|
|
I can only imagine OnDoSomethingCompletedAsync being called twice in a row without a call to Foo() inbetween, so that isWorking is set to false when the second call to OnDoSomethingCompletedAsync is made.
I'm not sure if this can happen after two calls to Foo, and the (rare?) case that both async methods will be called after each other. I can't reproduce this behavior even in a while loop on my machine, though.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
OnDoSomethingCompletedAsync is called only through the code shown above. In short, it can be only be called when DoSomething is finished executing asynchronously. And DoSomething won't be started if it's already running. Bah.
Joe Woodbury writes below that I should have declared the fields volatile. I thought using a lock would be sufficient, but I will try the volatile declaration.
Life, family, faith: Give me a visit.
From my latest post: "A lot of Christians struggle, perhaps at a subconscious level, about the phrase "God of Israel". After all, Israel's God is the God of Judaism, is He not? And the God of Christianity is not the God of Judaism, right?"
Judah Himango
|
|
|
|
|
I also considered using volatile, but I found out something different - I inserted some WriteLines to the methods, and this case happens quite a lot of times:
Enter Foo
Do something
Enter Result <---- huh? Shouldn't there be a lock?
Exit Result
Exit Foo
However, declaring the syncObject as static prohibits this case.
Maybe the lock isn't working properly?
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
I can see a very narrow circumstance where it will fail. The problem is that isWorking is not declared volatile, so you aren't guaranteed it will actually be set before OnDoSomethingCompletedAsync() is invoked. If the optimizer caches the value and writes it after the scope of the lock, you could have a problem IF the thread switch happens just before that instruction.
Try private volatile bool isWorking;
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
