Re: Sockets but calling from different programs

On 23Oct2017 05:33, T Obulesu wrote: I'm new to python3 and scratching my head to write a program for this logic: The tutor list might be a better place for such questions, but since we're here... classA.py Class A: # class for socket communication basic init method that

Re: Sockets: IPPROTO_IP not supported

On Mon, 16 Jan 2017 10:17:06 +, Joseph L. Casale wrote: >> Trying to sniff Ethernet packets, I do this: >> >>s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_IP) >> >> but it results in this: >> >> $ sudo python3 sniff_survey.py >> Traceback (most recent call last)

RE: Sockets: IPPROTO_IP not supported

> Trying to sniff Ethernet packets, I do this: > >s = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_IP) > > but it results in this: > > $ sudo python3 sniff_survey.py > Traceback (most recent call last): > File "sniff_survey.py", line 118, in > s = socket

Re: sockets,threads and interupts

loial wrote: > I have threaded python script that uses sockets to monitor network ports. > > I want to ensure that the socket is closed cleanly in all circumstances. This > includes if the script is killed or interupted in some other way. > > As I understand it signal only works in the main thread

Re: sockets,threads and interupts

On Wednesday, 5 September 2012 21:29:12 UTC+5:30, Ramchandra Apte wrote: > On Wednesday, 5 September 2012 18:34:32 UTC+5:30, Chris Angelico wrote: > > > On Wed, Sep 5, 2012 at 10:54 PM, Ramchandra Apte > > wrote: > > > > > > > At least on Linux, if you kill a process using sockets, it takes

Re: sockets,threads and interupts

On Wednesday, 5 September 2012 18:34:32 UTC+5:30, Chris Angelico wrote: > On Wed, Sep 5, 2012 at 10:54 PM, Ramchandra Apte > wrote: > > > At least on Linux, if you kill a process using sockets, it takes about 10 > > seconds for socket to be closed. A program should try to close all > > resour

Re: sockets,threads and interupts

On Wed, Sep 5, 2012 at 10:54 PM, Ramchandra Apte wrote: > At least on Linux, if you kill a process using sockets, it takes about 10 > seconds for socket to be closed. A program should try to close all resources. > OS'es may take a long time to close a unclosed socket automatically. Err, that's

Re: sockets,threads and interupts

On Wednesday, 5 September 2012 11:26:16 UTC+5:30, Dieter Maurer wrote: > loial writes: > > > > > I have threaded python script that uses sockets to monitor network ports. > > > > > > I want to ensure that the socket is closed cleanly in all circumstances. > > This includes if the script is

Re: sockets,threads and interupts

loial writes: > I have threaded python script that uses sockets to monitor network ports. > > I want to ensure that the socket is closed cleanly in all circumstances. This > includes if the script is killed or interupted in some other way. The operating system should close all sockets automatic

Re: sockets,threads and interupts

On Tuesday, 4 September 2012 23:41:13 UTC+5:30, Grant Edwards wrote: > On 2012-09-04, MRAB wrote: > > > On 04/09/2012 16:26, loial wrote: > > >> I have threaded python script that uses sockets to monitor network > > >> ports. > > >> > > >> I want to ensure that the socket is closed cleanly i

Re: sockets,threads and interupts

On 2012-09-04, MRAB wrote: > On 04/09/2012 16:26, loial wrote: >> I have threaded python script that uses sockets to monitor network >> ports. >> >> I want to ensure that the socket is closed cleanly in all >> circumstances. This includes if the script is killed or interupted in >> some other way.

Re: sockets,threads and interupts

On 04/09/2012 16:26, loial wrote: I have threaded python script that uses sockets to monitor network ports. I want to ensure that the socket is closed cleanly in all circumstances. This includes if the script is killed or interupted in some other way. As I understand it signal only works in the

Re: Sockets accept() in child processes

On Thu, Apr 12, 2012 at 10:48 AM, Merwin wrote: > Le 12/04/2012 19:10, Dan Stromberg a écrit : > > >> I wonder if this'll do what you need: >> https://trac.calendarserver.**org/browser/CalendarServer/** >> trunk/twext/python/sendfd.py

Re: Sockets accept() in child processes

Le 12/04/2012 19:10, Dan Stromberg a écrit : I wonder if this'll do what you need: https://trac.calendarserver.org/browser/CalendarServer/trunk/twext/python/sendfd.py The problem is that this is Linux-only solution, and I would like to keep a multi-platform compatibility. There are other wa

Re: Sockets accept() in child processes

I wonder if this'll do what you need: https://trac.calendarserver.org/browser/CalendarServer/trunk/twext/python/sendfd.py On Thu, Apr 12, 2012 at 2:31 AM, Thibaut DIRLIK wrote: > Hi, > > I'm writing a multiprocess server with Python 3.2 and the multiprocessing > module. Here is my current impleme

Re: Sockets: Receiving C Struct

First, s.recv(4) is not guaranteed to always return 4 bytes. It could return 0, 1, 2, 3, or 4, wtih 4 being the most likely. To deal with this, I tend to use http://stromberg.dnsalias.org/~dstromberg/bufsock.html - but I suspect that Twisted has a way of dealing with it too. Then, to put your da

Re: sockets: bind to external interface

Hans Georg Schaathun wrote: Is there a simple way to find the external interface and bind a socket to it, when the hostname returned by socket.gethostname() maps to localhost? What seems to be the standard ubuntu configuration lists the local hostname with 127.0.0.1 in /etc/hosts. (I checked th

Re: sockets: bind to external interface

On Mon, 25 Apr 2011 23:18:05 +0200, Thomas Rachel wrote: : That is right, but I cannot see where he mentions the "direction" of the : socket. My fist thought was that he tries to have a server socket... Quite right. I thought it was implied by the need to bind :-) Sorry for the lack of deta

Re: sockets: bind to external interface

On Tue, Apr 26, 2011 at 7:18 AM, Thomas Rachel wrote: > Am 25.04.2011 22:30, schrieb Chris Angelico: > >> If you don't care what port you use, you don't need to bind at all. >> That may be why it's not mentioned - the classic TCP socket server >> involves bind/listen/accept, and the classic TCP cl

Re: sockets: bind to external interface

Am 25.04.2011 22:30, schrieb Chris Angelico: If you don't care what port you use, you don't need to bind at all. That may be why it's not mentioned - the classic TCP socket server involves bind/listen/accept, and the classic TCP client has just connect; bind/connect is a lot less common. That

Re: sockets: bind to external interface

Am 25.04.2011 22:14 schrieb Hans Georg Schaathun: On Tue, 26 Apr 2011 05:49:07 +1000, Chris Angelico wrote: : The way you talk of "the" external interface, I'm assuming this : computer has only one. Is there a reason for not simply binding to : INADDR_ANY aka 0.0.0.0? Ah. That's wha

Re: sockets: bind to external interface

On Tue, Apr 26, 2011 at 6:24 AM, Hans Georg Schaathun wrote: > Hmmm.  socket.INADDR_ANY is an integer and bind insists on a string > for the hostname (Python 2.6).  Is there any use for the integer > constant?  "0.0.0.0" does exactly what I wanted though.  Thanks again. Apologies - I've done mos

Re: sockets: bind to external interface

On Tue, Apr 26, 2011 at 6:14 AM, Hans Georg Schaathun wrote: > :  The way you talk of "the" external interface, I'm assuming this > :  computer has only one. Is there a reason for not simply binding to > :  INADDR_ANY aka 0.0.0.0? > > Ah.  That's what I really wanted.  Thanks a lot.  I wonder why

Re: sockets: bind to external interface

On Mon, 25 Apr 2011 21:14:51 +0100, Hans Georg Schaathun wrote: : : The way you talk of "the" external interface, I'm assuming this : : computer has only one. Is there a reason for not simply binding to : : INADDR_ANY aka 0.0.0.0? : : Ah. That's what I really wanted. Thanks a lot. I wond

Re: sockets: bind to external interface

On Tue, 26 Apr 2011 05:49:07 +1000, Chris Angelico wrote: : You can run 'ifconfig' without being root, so there must be a way. At : very worst, parse ifconfig's output. Of course, but I am not sure that's simpler than the manual solution. Especially since there is more than one version of ifc

Re: sockets: bind to external interface

On Apr 25, 3:49 pm, Chris Angelico wrote: > On Tue, Apr 26, 2011 at 5:37 AM, Hans Georg Schaathun > wrote: > > > Has anyone found a simple solution that can be administered without > > root privileges?  I mean simpler than passing the ip address > > manually :-) > > You can run 'ifconfig' withou

Re: sockets: bind to external interface

On Tue, Apr 26, 2011 at 5:37 AM, Hans Georg Schaathun wrote: > Has anyone found a simple solution that can be administered without > root privileges?  I mean simpler than passing the ip address > manually :-) You can run 'ifconfig' without being root, so there must be a way. At very worst, parse

Re: Sockets and xml problem

On May 28, 3:23 pm, Stefan Behnel wrote: > kak...@gmail.com, 28.05.2010 13:50: > > > Hi in the following code > > > class MyClientHandler(SocketServer.BaseRequestHandler): > >      def handle(self): > >          print self.client_address, now( ) > >          time.sleep(5) > >          while True:

Re: Sockets and xml problem

kak...@gmail.com, 28.05.2010 13:50: Hi in the following code class MyClientHandler(SocketServer.BaseRequestHandler): def handle(self): print self.client_address, now( ) time.sleep(5) while True: xmltxt = self.request.recv(1024)<--is this ok - enough?

Re: Sockets and threading

> zayatzz (z) wrote: >z> Im trying to get aquinted to python on bit more basic level and am >z> following socket and threading programming tutorials from these 2 >z> addresses : >z> http://heather.cs.ucdavis.edu/~matloff/Python/PyNet.pdf >z> http://heather.cs.ucdavis.edu/~matloff/Python/PyTh

Re: Sockets and threading

En Sun, 12 Jul 2009 16:16:29 -0300, zayatzz escribió: while 1: k = self.myclntsock.recv(1) if k == "": break srvr.vlock.acquire() srvr.v += k srvr.vlock.releas

Re: sockets -- basic udp client

On Feb 17, 12:15 pm, [EMAIL PROTECTED] (Douglas Wells) wrote: > > For example: > > > import socket, sys > > > host =  'localhost'  #sys.argv[1] > > port = 3300 > > s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) > > > s.settimeout(1.0) > > buf = '' > > > data = 'hello world' > > num_sent = 0 >

Re: sockets -- basic udp client

In article <[EMAIL PROTECTED]>, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: I have had some difficulty following the assertions, corrections, and misquoting in this article thread, so apologies in advance if I have missed a correction or misunderstood an assertion. [ quoting partially corre

Re: sockets -- basic udp client

In article "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > If you don't care about the address of the sender, e.g. you are not > going to send anything back, is there an advantage to using recv()? At the system call level, recv() is marginally faster since there's less data to pass back and fort

Re: sockets -- basic udp client

Paul Rubin wrote: > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: >> Historically, though, the ultimate authority on this kind of stuff is >> Richard Stevens and his Unix and TCP/IP books >> >> I recommend these books if you want to get into network programming. > > I keep wanting to get that bo

Re: sockets -- basic udp client

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Historically, though, the ultimate authority on this kind of stuff is > Richard Stevens and his Unix and TCP/IP books > > I recommend these books if you want to get into network programming. I keep wanting to get that book, but it gets older and o

Re: sockets -- basic udp client

If you don't care about the address of the sender, e.g. you are not going to send anything back, is there an advantage to using recv()? Or, as a matter of course should you always use recvfrom() with udp sockets? I don't know of a reason why you couldn't use recvfrom() all the time, and that is w

Re: sockets -- basic udp client

On Feb 16, 6:32 am, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > >> That example is plain wrong; looks like some TCP code but with   > >> SOCK_STREAM   > >> blindy replaced with SOCK_DGRAM. connect, sendall and recv are not used   > >> for UDP; sendto and recvfrom are used instead. There are so

Re: sockets -- basic udp client

On Feb 16, 6:18 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > Here is the example above converted to a more straightforward udp > client that isolates the part I am asking about: > > import socket, sys > > host =  'localhost'

Re: sockets -- basic udp client

En Sat, 16 Feb 2008 05:56:39 -0200, 7stud <[EMAIL PROTECTED]> escribi�: >> > while 1: >> >     buf = s.recv(2048) >> >     if not len(buf): >> >         break >> >     print "Received: %s" % buf >> >> > As far as I can tell, the if statement: >> >> > if not len(buf): >> >    break >> >> > does n

Re: sockets -- basic udp client

Here is the example above converted to a more straightforward udp client that isolates the part I am asking about: import socket, sys host = 'localhost' #sys.argv[1] port = 3300 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM

Re: sockets -- basic udp client

On Feb 15, 6:48 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > En Fri, 15 Feb 2008 20:24:19 -0200, 7stud <[EMAIL PROTECTED]>   > escribió: > > > > > My question pertains to this example: > > > #!/usr/bin/env python > > > import socket, sys, time > > > host = sys.argv[1] > > textport = sys.arg

Re: sockets -- basic udp client

En Fri, 15 Feb 2008 20:24:19 -0200, 7stud <[EMAIL PROTECTED]> escribió: > My question pertains to this example: > > #!/usr/bin/env python > > import socket, sys, time > > host = sys.argv[1] > textport = sys.argv[2] > > s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) > try: > port = int(

Re: sockets: why doesn't my connect() block?

On Nov 19, 4:45 pm, [EMAIL PROTECTED] wrote: > a better question is why you are not using higher level libraries, > such as twisted I don't know about Mr. 7stud, but when I was doing a networking class, the prof recommended that we use C++ to learn socket programming. Students asked the obvious qu

Re: sockets: why doesn't my connect() block?

On Nov 17, 11:32 pm, 7stud <[EMAIL PROTECTED]> wrote: > According to "Python in a Nutshell(2nd)", p. 523: > > connect: s.connect((host, port)) > ... > Blocks until the server accepts or rejects the connection attempt. > > However, my client program ends immediately after the call to > connect()--

Re: sockets: why doesn't my connect() block?

On Nov 18, 3:08 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > > ...listen() gets > the initial connect() packet. accept() then is used to transfer the > connection onto a /new/ work socket (freeing the listen socket to catch > more connections) > Thanks. -- http://mail.python.org/mailman/lis

Re: sockets: why doesn't my connect() block?

7stud wrote: > If my platform accepted the connection, then why does my server > program have to call accept()? By making the listen() call, you've indicated your willingness to accept connections. The accept() call just gives you a file descriptor for the accepted connection (it's perhaps a littl

Re: sockets: why doesn't my connect() block?

On Nov 18, 10:40 am, 7stud <[EMAIL PROTECTED]> wrote: > If it accepted > the connection, then why do I have to call accept()? That should read: If my platform accepted the connection, then why does my server program have to call accept()? -- http://mail.python.org/mailman/listinfo/python-list

Re: sockets: why doesn't my connect() block?

On Nov 18, 8:18 am, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Sat, 17 Nov 2007 21:32:50 -0800 (PST), 7stud <[EMAIL PROTECTED]> wrote: > >According to "Python in a Nutshell(2nd)", p. 523: > > >connect: s.connect((host, port)) > >... > >Blocks until the server accepts or rejects the conne

Re: sockets: why doesn't my connect() block?

On Sat, 17 Nov 2007 21:32:50 -0800 (PST), 7stud <[EMAIL PROTECTED]> wrote: >According to "Python in a Nutshell(2nd)", p. 523: > >connect: s.connect((host, port)) >... >Blocks until the server accepts or rejects the connection attempt. > >However, my client program ends immediately after the call

Re: sockets, gethostname() changing

I figured something out that succeeded in making the hostname constant, and it allows me to run the socket programs without error. I'm posting what I did for future seekers. This is for mac os 10.4.7: 1) In System Preferences>Sharing, there is a name entered there: Computer Name: John S

Re: sockets, gethostname() changing

On May 24, 8:04 pm, 7stud <[EMAIL PROTECTED]> wrote: > Hi, > > I'm experimenting with a basic socket program(from a book), and both > the client and server programs are on my computer. In both programs, > I call socket.gethostname(), but I discovered that when I am connected > to the internet, bo

Re: sockets, gethostname() changing

7stud wrote: [...] > > The strange thing is: the hostname and port in the output are not what > I'm using in my server program: > - > import socket > > s = socket.socket() > > print "made changes 2" > > host = socket.gethostname() #I'm not connected to the internet when I > use this li

Re: sockets, gethostname() changing

>For local testing it is *much* easier to have your client >and server use IP address 127.0.0.1 According to my book, an address is a tuple of the form (hostname, port), so I didn't know what you meant by using 127.0.0.1 as the address. I played around with it, and using the tuple ("127.0.0.1", 1

Re: sockets, gethostname() changing

<[EMAIL PROTECTED]> wrote: ... > > and I'm not connected to the internet and I run the program, I get: > > > > my-names-computer.local > > > > When I'm connected to the internet, I get: > > > > dialup-9.999.999.999.dial9.xxx.level9.net > > That would bug me to high hell. A router in the mi

Re: sockets, gethostname() changing

En Fri, 25 May 2007 00:04:04 -0300, 7stud <[EMAIL PROTECTED]> escribió: > I'm experimenting with a basic socket program(from a book), and both > the client and server programs are on my computer. In both programs, > I call socket.gethostname(), but I discovered that when I am connected > to th

Re: sockets, gethostname() changing

On May 24, 8:50 pm, 7stud <[EMAIL PROTECTED]> wrote: > Thanks for the response. > > On May 24, 9:24 pm, [EMAIL PROTECTED] wrote: > > > I can't imagine why your hostname would be changing, unless you > > installed some of their proprietary software thats messing around with > > things. > > When I

Re: sockets, gethostname() changing

7stud wrote: > Hi, > > I'm experimenting with a basic socket program(from a book), and both > the client and server programs are on my computer. In both programs, > I call socket.gethostname(), but I discovered that when I am connected > to the internet, both the client and server hang and nothi

Re: sockets, gethostname() changing

Thanks for the response. On May 24, 9:24 pm, [EMAIL PROTECTED] wrote: > I can't imagine why your hostname would be changing, unless you > installed some of their proprietary software thats messing around with > things. When I first started using Terminal, I noticed that the prompt in Terminal c

Re: sockets, gethostname() changing

On May 24, 8:04 pm, 7stud <[EMAIL PROTECTED]> wrote: > Hi, > > I'm experimenting with a basic socket program(from a book), and both > the client and server programs are on my computer. In both programs, > I call socket.gethostname(), but I discovered that when I am connected > to the internet, bo

Re: Sockets in python

OneMustFall a écrit : > >> What's your set-up and which cord are you pulling? >> > > Well i now i think the clue is in the OS, i have sniffed and it seems > that Twisted have no magic. > It is seems that i simply tested things in a wrong way - > when i pulled cord from ethernet card windows deter

Re: Sockets in python

> What's your set-up and which cord are you pulling? > Well i now i think the clue is in the OS, i have sniffed and it seems that Twisted have no magic. It is seems that i simply tested things in a wrong way - when i pulled cord from ethernet card windows determined that network lost and started

Re: Sockets in python

OneMustFall wrote: > Reciently i wrote a simple client (in twisted) using Reconnecting > Factory. > That client logins to my socket server.. and that`s it. > > Interesting thing is that it is seems that twisted client, > sends some ping on a TCP level without sending any da

Re: sockets, where can I find documentation?

Thanks everyone for such a quick response. Brilliant! John Pote "John Pote" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi all, > > I want to use python on a server to access incoming TCP port accesses. So > I need to use the socket interface which is new to me. To quote the P

Re: sockets, where can I find documentation?

John Pote: >I want to use python on a server to access incoming TCP port accesses. So I >need to use the socket interface which is new to me. You may also want to look at Twisted: http://twistedmatrix.com/trac/ >Where can I get the various papers mentioned in the manual? And as I like >books s

Re: sockets, where can I find documentation?

For a good general book on networking with python, try Foundations of Python Network Programming by John Goerzen. http://www.amazon.com/gp/product/1590593715/qid=1141390241/sr=1-9/ref=sr_1_9/104-7194399-1227965?s=books&v=glance&n=283155 -- http://mail.python.org/mailman/listinfo/python-list

Re: sockets, where can I find documentation?

On Fri, 03 Mar 2006 11:41:05 GMT, John Pote wrote: > Where can I get the various papers mentioned in the manual? And as I like > books sitting on the shelf can someone recommend a book on sockets. Unix Network Programming by Stevens -- USB Priests for only 10$ -- http://mail.python.org/mailma

Re: sockets programming with python on mobile phones

Thanks ! well..acutally this is siddharth dave i am a BIG al pacino fan ..(and before joning this grp i had just watched 'scent of a woman") hence this pun on myself!! neways thanks for replying ps: dear edwards watch 'scent of a woman' and u will forget 'doniie brosco'..:-) AL pacino won an osca

Re: sockets programming with python on mobile phones

On 2006-01-26, al pacino <[EMAIL PROTECTED]> wrote: > Is it possible to write applications using sockets for network > programming on MOBILE Phones( using Python on mobile phones > such as nokia 66* series ) > > actually i want my mobile to 'TALK' to my pc 'WIRELESSLY' so i can send > data between

Re: sockets

> >> the following code works perfectly >> import socket, sys >> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >> s.connect(("www.python.org", 80)) >> s.send("GET") here, You need to speak HTTP protocol. I would suggest to change s.send( "GET / HTTP/1.0\x0d\x0a\x0d\x0a" ) >> whi

Re: sockets

archana sambandam wrote: > the following code works perfectly > import socket, sys > s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) > s.connect(("www.python.org", 80)) > s.send("GET") > while 1: > buf = s.recv(1000) > if not buf: > break > sys.stdout.write(buf)

Re: Sockets on Windows and Mac

rodmc wrote: > I am currently importing the socket library when I write the programs, > I have had no problems with it on my PC at work, but the Mac at home > steadfastly refuses to work. One rule about asking for help in forums like this is to provide adequate background detail about your envir

Re: Sockets on Windows and Mac

On 2006-01-08, rodmc <[EMAIL PROTECTED]> wrote: > I am currently importing the socket library when I write the programs, > I have had no problems with it on my PC at work, but the Mac at home > steadfastly refuses to work. Well, with details like that, we'll have your problem figured out in no ti

Re: Sockets on Windows and Mac

Hi Peter, I am currently importing the socket library when I write the programs, I have had no problems with it on my PC at work, but the Mac at home steadfastly refuses to work. As for existing libraries, I am new to Python so am kean to avoid re-inventing the wheel :-) Cheers, rod -- http://

Re: Sockets on Windows and Mac

I am on 10.3, I keep getting exceptions when it hits lines like mySocket.bind (SERVER_IP, 2727 ) or mySocket = socket.socket(socket.AF_NET,socket.SOCK_STREAM) The code I am using is copied from a tutorial on a website somewhere. Cheers, rod -- http://mail.python.org/mailman/listinfo/python-li

Re: Sockets on Windows and Mac

Hi Peter, I am currently importing the socket library when I write the programs, I have had no problems with it on my PC at work, but the Mac at home steadfastly refuses to work. As for existing libraries, I am new to Python so am kean to avoid re-inventing the wheel :-) Cheers, rod -- http://

Re: Sockets on Windows and Mac

rodmc <[EMAIL PROTECTED]> wrote: > I am new to Python and have been writing some socket based programmes > on Windows (with some success), however I am unable to get them to work > on Mac. > > Are there differences in the way the socket module works on Windows and > Mac? I would appreciate any si

Re: Sockets on Windows and Mac

rodmc wrote: > I am new to Python and have been writing some socket based programmes > on Windows (with some success), however I am unable to get them to work > on Mac. > > Are there differences in the way the socket module works on Windows and > Mac? I would appreciate any simple code samples peo

Re: Sockets on Windows and Mac

rodmc wrote: > I am new to Python and have been writing some socket based programmes > on Windows (with some success), however I am unable to get them to work > on Mac. Please elaborate on "unable to get them to work". What problems do you see? In my experience, there is no difference with the Ma

Re: Sockets: code works locally but fails over LAN

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 >

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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()? -

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

1. Python 2.3.4 2. Win98 and Win2k Professional -- http://mail.python.org/mailman/listinfo/python-list

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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. >

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

>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,

Re: Sockets: code works locally but fails over LAN

* 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

Re: Sockets: code works locally but fails over LAN

"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

Re: Sockets: code works locally but fails over LAN

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

Re: Sockets: code works locally but fails over LAN

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

  1   2   >