n00m wrote:
[...]
> Btw, the newest oops in the topic's subject is:
> the code does not work in the case of:
>
> sqls_host, sqls_port = '192.168.0.8', 1433
> proxy_host, proxy_port = '192.168.0.3', 1434
> ## proxy_host, proxy_port = '127.0.0.1', 1434
> ## proxy_host, proxy_port = '', 1434
>
Thanks, Bryan, for the details!
Btw, the newest oops in the topic's subject is:
the code does not work in the case of:
sqls_host, sqls_port = '192.168.0.8', 1433
proxy_host, proxy_port = '192.168.0.3', 1434
## proxy_host, proxy_port = '127.0.0.1', 1434
## proxy_host, proxy_port = '', 1434
I.e. w
n00m wrote:
> Btw, why we need send() if there is sendall()?
Mostly because sendall() can block, even if you do all the
select() and setblocking() magic. That's no problem in the
threaded architecture we're using, but a deal-breaker for a
single-threaded server.
--
--Bryan
--
http://mail.pytho
I was trying to test the send() vs sendall() like this:
x=send(data)
print len(data)-x > 0 ? (when the code fails)
but I could not reproduce the failures anymore.
As if the lan got "refreshed" after the first
using of sendall() instead of send().
Btw, why we need send() if there is sendall()?
-
Bryan Olson wrote:
> Ah, yes, I see. (In my defense, I had already fixed that bug in
> my second version.)
1.
Yes! I myself noticed that, but your 2nd version looks
a bit more verbose.
2.
This all means... what? ONLY send() vs sendall() matters?
Sometimes send() really sends ALL and my version work
n00m wrote:
> Bryan;
> Look at how I corrected your the very first version
> (see added arguments in both functions). And now it
> really can handle multiple connections!
Ah, yes, I see. (In my defense, I had already fixed that bug in
my second version.)
--
--Bryan
--
http://mail.python.or
Bryan;
Look at how I corrected your the very first version
(see added arguments in both functions). And now it
really can handle multiple connections!
import socket, thread
sqls_host, sqls_port = '127.0.0.1', 1433
proxy_host, proxy_port = '127.0.0.1', 1434
# How I tested it:
# sqls_host, sqls_p
Dennis Lee Bieber wrote:
> Bryan Olson declaimed the following in comp.lang.python:
>
>>No, my guess is that you're running an old version of Python.
>>The constant was added in the source on 27 Nov 2003; I'm not
>
>
> Are you sure of that 2003?
Yes, but that's when it went into the sourc
1.
Python 2.3.4
2.
Win98 and Win2k Professional
--
http://mail.python.org/mailman/listinfo/python-list
n00m wrote:
> Bryan wrote:
> PS Yes! Your last version works like a champ. It easily handles up
> to 5 instances of my.vbs! Except of this thing:
>
>>AttributeError: 'module' object has no attribute 'SHUT_WR'
>
> Seems it's a pure Unix constant.
Definitely not. Are you sure you've got a proper
n00m wrote:
> Your last version works like a champ. It easily handles up
> to 5 instances of my.vbs! Except of this thing:
>
>>AttributeError: 'module' object has no attribute 'SHUT_WR'
>
> Seems it's a pure Unix constant.
No, my guess is that you're running an old version of Python.
The con
Bryan wrote:
> Do you want to be a network engineer?
lol... definetely not! It's just my curiosity.
At my work my tools are: vba, vbs, jet-sql (ms access),
t-sql (ms sql server). The pretty humble set.
> My first two guess are:
> The client is trying to make more than one connection.
> Put
n00m wrote:
> My today's tests (over LAN).
> I think *it* will drive me mad very soon.
Network programming is like that. Just because something worked
once doesn't mean it really works. I had guessed two causes for
the behavior you were seeing, and either could result in sporadic
failures.
>
My today's tests (over LAN).
I think *it* will drive me mad very soon.
Firstly I tested both Bryan's codes. And they worked fine!
Just as if they were tested locally!
Then I tested Fredrik suggestion. And it worked out too.
Expect unexpected, - as they say.
At last I decided to test my own versi
I wrote:
> Below is a version that respects ^C to terminate
> more-or-less cleanly.
Oops, one more bug^H^H^H improvement. I forgot to shutdown
writing.
> import socket, threading, select
>
> sqls_host, sqls_port = '192.168.0.3', 1443
> proxy_host, proxy_port = '', 1434
>
>
> def start_d
n00m wrote:
>>Bryan;
>
> I tested your code locally (in I*D*L*E) - it works fine!
Glad it worked, but I'd still disrecommend IDLE for that
version. Threads may live after the program seems to be done
(and may still own the port you need). Below is a version that
respects ^C to terminate more-or
>Bryan;
I tested your code locally (in I*D*L*E) - it works fine!
And of course I'll test it over LAN but only tomorrow - at work.
See the picture of my IDLE window with output of your code:
http://free.7host02.com/n00b/socket_Br.gif
Note the 4th line in Blue: there Z is the name of my home machine,
* n00m <[EMAIL PROTECTED]> [2005-08-31 05:45]:
> import socket, thread
> host, port = '192.168.0.3', 1434
> s1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s2.connect((host, 1433))
> s1.bind((host, port))
I think the problem is that
"n00m" <[EMAIL PROTECTED]> wrote:
> PEOPLE, WHY ON THE EARTH IT DOES NOT WORK OVER LAN ???
what happens if you change
s1.bind((host, port))
to
s1.bind(("", port))
?
--
http://mail.python.org/mailman/listinfo/python-list
n00m wrote:
> import socket, thread
> host, port = '192.168.0.3', 1434
Consider using INADDR_ANY instead of the specific host IP
address. The empty string will resolve to INADDR_ANY if passed
as the host to bind(). (Though that's not the problem.)
> s1 = socket.socket(socket.AF_INET, socket.S
On 2005-08-31, Bryan Olson <[EMAIL PROTECTED]> wrote:
>>>2. I'm not at all sure that accessing the same socket object
>>>simultaneously from two threads is safe.
>>
>> It's OK under Unix. Having one thread handle rx and a
>> different one handle tx is a pretty widely used method.
>>
>> Don't know
Grant Edwards wrote:
> Peter Hansen wrote:
>
>
>>2. I'm not at all sure that accessing the same socket object
>>simultaneously from two threads is safe.
>
> It's OK under Unix. Having one thread handle rx and a
> different one handle tx is a pretty widely used method.
>
> Don't know abou
Thank you all for your replies!
1.
repr() is not what I need (currently).
I'd better like to see the pure text of "talkings" between VBS and SQL
Server.
2.
Jp, thank you very much for the links!
I just oblige to test this Twisted stuff, but I'm afraid it's a bit
above my head
so far.
And, frankly s
On 31 Aug 2005 06:03:00 -0700, n00m <[EMAIL PROTECTED]> wrote:
>import socket, thread
>host, port = '192.168.0.3', 1434
>s1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>s2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>s2.connect((host, 1433))
>s1.bind((host, port))
>s1.listen(1)
>cn,
On 2005-08-31, Peter Hansen <[EMAIL PROTECTED]> wrote:
> 2. I'm not at all sure that accessing the same socket object
> simultaneously from two threads is safe.
It's OK under Unix. Having one thread handle rx and a
different one handle tx is a pretty widely used method.
Don't know about Win32.
n00m wrote:
> import socket, thread
> host, port = '192.168.0.3', 1434
> s1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s2.connect((host, 1433))
> s1.bind((host, port))
> s1.listen(1)
> cn, addr = s1.accept()
>
> def VB_SCRIPT():
>
import socket, thread
host, port = '192.168.0.3', 1434
s1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s2.connect((host, 1433))
s1.bind((host, port))
s1.listen(1)
cn, addr = s1.accept()
def VB_SCRIPT():
while 1:
data = cn.re
27 matches
Mail list logo