On 01/21/2015 09:38 AM, Les Mikesell wrote:
If you can change the client, and you want to keep essentially
re-using the same socket after a reboot
Not the same socket, but the same client port number.
, can't you simply send a RST
on it when starting up
I don't think so. That would also be
On 01/21/2015 08:49 AM, Glenn Eychaner wrote:
Diagnosis:
the previous behavior of
receiving a 0-length recv() on the old server socket is unsupported and
unreliable.
You mention that a lot, and it might help to understand why that happens.
A 0 length recv() on a standard (blocking) socket indi
On Wed, Jan 21, 2015 at 10:49 AM, Glenn Eychaner wrote:
> > 2) Protocol change: The server never writes to the socket in the existing
> protocol, and can therefore never find out that the connection is dead.
> Writing to the socket would reveal this. But what happens if the server writes
> to the
I'd like to thank everyone for their replies and advice. I'm sorry it took so
long for me to respond; I took a long weekend after a long shift. Some
remaining questions can be found in the final section of this posting. The
summary (I hope i have all of this correct):
Problem:
A DOS box (client) c
On Fri, Jan 16, 2015 at 01:23:56PM -0600, Les Mikesell wrote:
> And, without keepalives enabled,
> you still won't get an error on the write.
No, if the other end is up after a reboot, you'll get an immediate
error and socket close.
That's assuming the window isn't full; if it is, you'll have to
On Fri, Jan 16, 2015 at 1:13 PM, Fred Smith
wrote:
>> >
>> > Normally if you care about knowing if the other end of a connection is
>> > gone you could enable keepalives on the socket
>>
>> That’s also an appropriate fix, especially when the protocol inherently has
>> long periods of idle time, l
On Fri, Jan 16, 2015 at 11:34:28AM -0700, Warren Young wrote:
> On Jan 16, 2015, at 11:29 AM, Les Mikesell wrote:
>
> > On Fri, Jan 16, 2015 at 12:21 PM, Warren Young wrote:
> >>
> >> A different fix is to exploit the real-time nature of video camera imagery
> >
> > Normally if you care about
On Jan 16, 2015, at 11:29 AM, Les Mikesell wrote:
> On Fri, Jan 16, 2015 at 12:21 PM, Warren Young wrote:
>>
>> A different fix is to exploit the real-time nature of video camera imagery
>
> Normally if you care about knowing if the other end of a connection is
> gone you could enable keepaliv
On Fri, Jan 16, 2015 at 12:21 PM, Warren Young wrote:
>
> A different fix is to exploit the real-time nature of video camera imagery:
> if your Python app goes more than a second without receiving an image frame,
> it can presume that the DOS box has disappeared again, and drop its conn. By
>
A couple more thoughts...
On Jan 16, 2015, at 10:42 AM, Warren Young wrote:
> On Jan 15, 2015, at 11:40 AM, Glenn Eychaner wrote:
>
>> When the DOS box exits, crashes, or is rebooted, it fails to shut down the
>> socket properly.
>
> Yes, that’s what happens when you use an OS that doesn’t im
On Jan 15, 2015, at 11:40 AM, Glenn Eychaner wrote:
> When the DOS box exits, crashes, or is rebooted, it fails to shut down the
> socket properly.
Yes, that’s what happens when you use an OS that doesn’t implement sockets in
kernel space: there is no program still running that can send the RST
On Fri, Jan 16, 2015 at 6:18 AM, Glenn Eychaner wrote:
>
> I was super-surprised by the change, in that I fully tested the upgrade on
> my simulator system before deploying, and still got bit on deployment.
I'm not sure I completely understand the scenario, but it seems wrong
for it to have worke
What about SO_LINGER at the Linux side, have you tried that?
http://stackoverflow.com/questions/3757289/tcp-option-so-linger-zero-when-its-required
On Fri, Jan 16, 2015 at 1:18 PM, Glenn Eychaner wrote:
>> Since you always use the same local port -
>> maybe you need to set SO_REUSEADDR option.
>
[I wish I knew how to get the mailing list to thread my replies properly in the
archives; I subscribe to the daily digest, and replying to that doesn't do it.]
Greg Lindahl wrote:
> On Thu, Jan 15, 2015 at 03:40:08PM -0300, Glenn Eychaner wrote:
>
> > My only theory is that this has something to
Since you always use the same local port -
maybe you need to set SO_REUSEADDR option.
Greetings from Germany
Alex
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
On Thu, Jan 15, 2015 at 03:40:08PM -0300, Glenn Eychaner wrote:
> My only theory is that this has something to do with non-ephemeral ports and
> socket reuse, but I'm not sure what.
If you want a quick detection that the link is dead, have the server
occasionally send bytes to the dos box. You wi
I will try to explain this as best I can. I have two computers; one a
Supermicro X10SAE running CentOS 6, the other a very old DOS box.[*] The DOS
box runs a CCD camera, sending images via Ethernet to the X10SAE. Thus, the
X10SAE runs a Python server on port 5700 (a socket which binds to 5700 and
17 matches
Mail list logo
