Need help

[brian]

I am working with a 3rd party credit card company that is using Python
version 2.2.2. They are using the httplib module to post data to my
server which is a dedicated server with no firewall or any
rate-limiting or DDoS prevention.

Every time they try, the first 2 posts are successful and it always
throws this error on the third attempt. It is reproducable every time
they run the program.

 

[Fredrik Lundh]

( http://www.catb.org/~esr/faqs/smart-questions.html#bespecific )

I am working with a 3rd party credit card company that is using Python
version 2.2.2. They are using the httplib module to post data to my
server which is a dedicated server with no firewall or any
rate-limiting or DDoS prevention.

Every time they try, the first 2 posts are successful and it always
throws this error on the third attempt.

what error? if you/they get a traceback, please post the traceback. if
"throw an error" means something else, please explain.

</F>

 

[brian]

They tell me the error is Recv Timed Out.

 

[Peter Hansen]

They tell me the error is Recv Timed Out.

It would probably go much faster if "they" were the
ones asking the questions and describing their
situation.

Otherwise it sounds like a case of the blind leading the blind.
You don't know the specifics of their situation, and
troubleshooting is hard enough without trying to do it
through a middleman...

(However, it can be done... it's just damn hard. If
you/they for some reason don't want to hire somebody
to investigate and resolve the problem, I guess you'll
need patience and imagination. Here's a first step:
how far apart are these requests? If they're very
close together, what happens if they insert, say, a
few seconds delay between each one?)

-Peter

 

[Heiko Wundram]

Am Dienstag, 1. März 2005 21:53 schrieb brian:

They tell me the error is Recv Timed Out.

This sounds like a socket level (TCP/IP stack) error, which might be caused by
a malfunctioning gateway or network device (likely), an error in the
operating system or network device driver they use (unlikely), or a
combination of several malfunctions.

But, this certainly isn't an error that's Python related (IMHO), so you better
tell them to check their hardware...

--
--- Heiko.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCJNkvf0bpgh6uVAMRAvBwAJ9cHXfAtaJUY+eIuJgAGgYOowvT+wCfSmW5
/hPhZQpCNeA9VEW4DV04fB0=
=a8EP
-----END PGP SIGNATURE-----

 

[brian]

I totally agree....but that being said...I want to make sure its not
something on my server causing the problem. Im on a windows 2003
server.

Let me also throw this into the mix....before we went down the HTTP
post route we first tried to post data directly into MSSQL, but we were
getting connection errors. Im inquiring with "them" if they also used
Python to do this, Im assuming the answer is yes.

 

[Peter Hansen]

I totally agree....but that being said...I want to make sure its not
something on my server causing the problem. Im on a windows 2003
server.

Python runs fine on a Windows 2003 server. Maybe they can
package up a stripped version of the code that still reproduces
the problem and you can just run it locally.

Alternatively, find a utility that can send "canned" HTTP
requests and use it to duplicate the effect of what they're
doing.

The key to troubleshooting any problem of this sort (complex,
networks, etc) is to partition. Come up with tests which
prove that the problem is on one side or the other, often
by eliminating the other side as a potential cause. You
can run stuff on your server, proving that it's not the
cause. You can do things like insert delays as I suggested
before (which will often make the problem go away, generally
leading quickly to a proof of exactly which component the
problem is in).

Also, you haven't mentioned that you've checked the logs
on your server and seen any evidence that the third request
was received. Nor that you've attempted to monitor the traffic
on the network using a utility that can show you exactly
what traffic went which way and when.

Let me also throw this into the mix....before we went down the HTTP
post route we first tried to post data directly into MSSQL, but we were
getting connection errors. Im inquiring with "them" if they also used
Python to do this, Im assuming the answer is yes.

There are so many things likely to be different in that situation
that I'm not sure you'll learn anything, unless exactly the
same error was produced, and probably not even then.

Keep in mind that there are people who do this sort of
troubleshooting work for money. Often they're well worth
it because they'll save you far more time and aggravation
than it will cost you to hire them...

-and-some-like-to-give-it-away-too-ly y'rs,
Peter

 

[brian]

When you say tools, can you give me one in particular that I can
install on my server to do what you were mentioning?

 

[Steve Holden]

When you say tools, can you give me one in particular that I can
install on my server to do what you were mentioning?

Good grief, man, are we to believe you are charging people money for
running this web server? Do you even know where IIS keeps its logs?

I take it you know what code on your server they are posting to? Have
you tried doing three manual posts in quick succession? From a local
browser? From a remote browser? Is anyone else using the same code
successfully? etc., etc., ...

In terms of capturing network traffic, take a look at www.ethereal.com -
it's a very good tool for capturing netwokr traffic, and will definitely
show you what's getting through to your server and what isn't. Open
source, multi-platform, just the ticket for problems like this.

regards
Steve

 

[brian]

Got code from the 3rd party, maybe someone can see something wrong with
it:

def sendDataHTTP( url, postData ):
# url format: http://www.blah.com/notrealurl

# postData is either a dictionary or list of dictionaries
# that contain the data that you want to post.

responseList = []
urlList = urlparse.urlparse( url )
host = urlList[1]
scriptPath = urlList[2]
if not type( postData ) == list: postData = [ postData ]
headers = { "Content-type": "application/x-www-form-urlencoded",
"Accept": "text/plain" }
conn = httplib.HTTPConnection( host )

for thisDict in postData:
params = urllib.urlencode( thisDict )
conn.request("POST", scriptPath, params, headers )
response = conn.getresponse()
responseList.append( (response.status,response.reason) )
conn.close()
return responseList

 

[gaudetteje]

I doubt it's a hardware issue... If these people have any knowledge of
computers, they would try connecting to other places to see if it gives
them the same error. It sounds obvious, but have them ping your DNS
alias as well as your IP address.

If they can't get anywhere else, then it's a local hardware issue to
them. If they can, run a traceroute program from them to you (or
vica-verca if you can) to see where the connection is halting. It may
be a hardware issue local to you. Do you have other clients with the
same problem? Can you ping them from your server? These are all
questions you should be using to troubleshoot.

If you can ping to/from client/server then this certainly isn't a
network hardware issue. And if it was connecting, but blocking a
specific port then your ICMP response would say that rather than "timed
out." My suggestion to you is get an answer to these questions and
post back here. You should have done this before ever even thinking
about looking at the source code. If you did, you should have posted
the results.

It sounds to me like they just don't have the correct hostname (or
their DNS service is down). Again, this could be seen from answering
the above questions.

G/L

Jay

 

[Peter Hansen]

It sounds to me like they just don't have the correct hostname (or
their DNS service is down). Again, this could be seen from answering
the above questions.

Hmm.... what can be seen from reading Brian's message is that
it clearly cannot be a simple matter of incorrect hostname,
or an inability to connect at all. He said they can connect
twice before they get the error.

And unfortunately there are many places where ICMP packets,
including "echo" and "echo response", have been disabled for
security reasons. The inability to ping does not necessarily
mean anything about the ability to establish TCP sessions.

In the end, however, it does seem unlikely that this has
much to do with Python...

-Peter