Opened 5 years ago

Closed 5 years ago

#7272 closed defect (fixed)

flashproxy-client socket.error exception on Windows

Reported by: aallai Owned by: dcf
Priority: High Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: dcf@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

flashproxy-client occasionally throws the following exception:

Socket error writing to local: '[Errno 10035] A non-blocking socket operation
could not be completed immediately'

Errno 10035 is WSAEWOULDBLOCK, set when a non-blocking socket attempts
an operation that cannot be completed without blocking. The exception breaks the connection between Tor and the flash proxy serving it.

Child Tickets

Change History (4)

comment:1 Changed 5 years ago by aallai

Status: newneeds_review

I have a fix for this at https://github.com/aallai/flashproxy.git, branch ticket#7272.

What I did was remove the setblocking call in listen_socket, so all the sockets block.
The client uses select so it should never block on reads. It can block on sends, but the
*Socket classes use sendall, so it seems like the intention was to block there.

Alternatively the *Socket classes could buffer the data and try resending at another time,
this would probably involve some extra threads though. Let me know if this approach
is better.

comment:2 in reply to:  1 Changed 5 years ago by dcf

Priority: minormajor
Status: needs_reviewneeds_revision

Replying to aallai:

I have a fix for this at https://github.com/aallai/flashproxy.git, branch ticket#7272.

What I did was remove the setblocking call in listen_socket, so all the sockets block.
The client uses select so it should never block on reads. It can block on sends, but the
*Socket classes use sendall, so it seems like the intention was to block there.

Okay, it looks reasonable.

I'd like you to edit the commit log. Saying that you removed a call to setblocking(0) is not enough. You also need to describe the error that the change fixes (exception on sendall on Windows) and why the program still works with blocking sockets.

You can just clobber the current head of your 7272 branch with one having a more descriptive log. (git commit --amend, git push --force.)

Alternatively the *Socket classes could buffer the data and try resending at another time,
this would probably involve some extra threads though. Let me know if this approach
is better.

comment:3 Changed 5 years ago by aallai

I fixed up the commit, it now explains the error briefly, and refers to this trac ticket.
I'll do this on future patches as well.

comment:4 Changed 5 years ago by dcf

Resolution: fixed
Status: needs_revisionclosed

Thanks, merged.

Note: See TracTickets for help on using tickets.