new socket API
Locked
 
|
Uhm, guys I really appreciate that I can use IPv6 but:
Yesterday I spent some time trying to open a socket given that I know the IP address and the port. The lack of documentation or suggested types sure wasn't helpful and I wished Pharo was statically typed so that I at least knew what I had to pass in. That's what I came up with: hostIP := (SocketAddressInformation forHost: anIpString service: '' flags: 0 addressFamily: SocketAddressInformation addressFamilyINET4 socketType: SocketAddressInformation socketTypeStream protocol: SocketAddressInformation protocolTCP) first socketAddress. socket := Socket new. socket connectTo: hostIP port: portNumber. There's gotta be a better way to do this. The whole API with arrays where you have to know the index, ByteArray objects, integer flags and so forth seems like a blast from the past. Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Philippe Marschall wrote:
> There's gotta be a better way to do this. > > The whole API with arrays where you have to know the index, ByteArray > objects, integer flags and so forth seems like a blast from the past. We could put some default behavior wrapper methods around this. But this is really a discussion for squeak-dev, as the IPv6 implementation originates from etoys/olpc. Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
so what is the next step?
stef On Aug 26, 2009, at 8:19 AM, Michael Rueger wrote: > Philippe Marschall wrote: > >> There's gotta be a better way to do this. >> >> The whole API with arrays where you have to know the index, ByteArray >> objects, integer flags and so forth seems like a blast from the past. > > > We could put some default behavior wrapper methods around this. > But this is really a discussion for squeak-dev, as the IPv6 > implementation originates from etoys/olpc. > > Michael > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Stef,
I am not sure exactly what should be next, but I do not think we can simply kick it back to squeak-dev any more than we can the GUI/IDE, streams, etc., as sockets are very important. I am slowly chipping away at things that are standing in the way of my first Pharo success story; the impact of sockets has been minimal, but that will change. When I get going, I will be looking carefully at how things behave when peers do not respond (only the calling thread should suffer). Dolphin's socket streams are nice; Pharo seems to lean toward a single read-write stream, which should be fine as long as it manages not to hobble the image when the wrong wire gets kicked. SSL via OpenSSL should be easy to use; that will be an interesting adventure, but it needs to happen. With all due respect to those who have disagreed, I'm still highly suspicious that the networking problems have far more to do with IPv6 vs. 4 than the OS. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Wednesday, August 26, 2009 7:21 AM To: [hidden email] Subject: Re: [Pharo-project] new socket API so what is the next step? stef On Aug 26, 2009, at 8:19 AM, Michael Rueger wrote: > Philippe Marschall wrote: > >> There's gotta be a better way to do this. >> >> The whole API with arrays where you have to know the index, ByteArray >> objects, integer flags and so forth seems like a blast from the past. > > > We could put some default behavior wrapper methods around this. > But this is really a discussion for squeak-dev, as the IPv6 > implementation originates from etoys/olpc. > > Michael > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Btw, while we're at it:
TCP sockets and UDP sockets have a different interface. Some messages can only be sent to TCP sockets others only to UDP sockets. Yet they are both represented by the same Socket class. Cheers Philippe Schwab,Wilhelm K wrote: > Stef, > > I am not sure exactly what should be next, but I do not think we can simply kick it back to squeak-dev any more than we can the GUI/IDE, streams, etc., as sockets are very important. I am slowly chipping away at things that are standing in the way of my first Pharo success story; the impact of sockets has been minimal, but that will change. When I get going, I will be looking carefully at how things behave when peers do not respond (only the calling thread should suffer). Dolphin's socket streams are nice; Pharo seems to lean toward a single read-write stream, which should be fine as long as it manages not to hobble the image when the wrong wire gets kicked. SSL via OpenSSL should be easy to use; that will be an interesting adventure, but it needs to happen. > > With all due respect to those who have disagreed, I'm still highly suspicious that the networking problems have far more to do with IPv6 vs. 4 than the OS. > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse > Sent: Wednesday, August 26, 2009 7:21 AM > To: [hidden email] > Subject: Re: [Pharo-project] new socket API > > so what is the next step? > > stef > > On Aug 26, 2009, at 8:19 AM, Michael Rueger wrote: > >> Philippe Marschall wrote: >> >>> There's gotta be a better way to do this. >>> >>> The whole API with arrays where you have to know the index, ByteArray >>> objects, integer flags and so forth seems like a blast from the past. >> >> We could put some default behavior wrapper methods around this. >> But this is really a discussion for squeak-dev, as the IPv6 >> implementation originates from etoys/olpc. >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> TCP sockets and UDP sockets have a different interface. Some messages
> can only be sent to TCP sockets others only to UDP sockets. Yet they are > both represented by the same Socket class. That sounds like a really easy and backward compatible refactoring (add two subclasses, fix the constructors, and push down methods). Why don't you submit a patch? Lukas > > Cheers > Philippe > > Schwab,Wilhelm K wrote: >> Stef, >> >> I am not sure exactly what should be next, but I do not think we can simply kick it back to squeak-dev any more than we can the GUI/IDE, streams, etc., as sockets are very important. I am slowly chipping away at things that are standing in the way of my first Pharo success story; the impact of sockets has been minimal, but that will change. When I get going, I will be looking carefully at how things behave when peers do not respond (only the calling thread should suffer). Dolphin's socket streams are nice; Pharo seems to lean toward a single read-write stream, which should be fine as long as it manages not to hobble the image when the wrong wire gets kicked. SSL via OpenSSL should be easy to use; that will be an interesting adventure, but it needs to happen. >> >> With all due respect to those who have disagreed, I'm still highly suspicious that the networking problems have far more to do with IPv6 vs. 4 than the OS. >> >> Bill >> >> >> >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse >> Sent: Wednesday, August 26, 2009 7:21 AM >> To: [hidden email] >> Subject: Re: [Pharo-project] new socket API >> >> so what is the next step? >> >> stef >> >> On Aug 26, 2009, at 8:19 AM, Michael Rueger wrote: >> >>> Philippe Marschall wrote: >>> >>>> There's gotta be a better way to do this. >>>> >>>> The whole API with arrays where you have to know the index, ByteArray >>>> objects, integer flags and so forth seems like a blast from the past. >>> >>> We could put some default behavior wrapper methods around this. >>> But this is really a discussion for squeak-dev, as the IPv6 >>> implementation originates from etoys/olpc. >>> >>> Michael >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Lukas Renggli wrote:
>> TCP sockets and UDP sockets have a different interface. Some messages >> can only be sent to TCP sockets others only to UDP sockets. Yet they are >> both represented by the same Socket class. > > That sounds like a really easy and backward compatible refactoring > (add two subclasses, fix the constructors, and push down methods). Why > don't you submit a patch? Yeah if it's as simple as that and it doesn't break any plugin or stuff. Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Philippe Marschall wrote:
> Lukas Renggli wrote: >>> TCP sockets and UDP sockets have a different interface. Some messages >>> can only be sent to TCP sockets others only to UDP sockets. Yet they are >>> both represented by the same Socket class. >> That sounds like a really easy and backward compatible refactoring >> (add two subclasses, fix the constructors, and push down methods). Why >> don't you submit a patch? > > Yeah if it's as simple as that and it doesn't break any plugin or stuff. And we find a solution for SocksSocket which is of course a subclass of Socket. Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
code code code :)
Stef On Aug 26, 2009, at 7:20 PM, Philippe Marschall wrote: > Philippe Marschall wrote: >> Lukas Renggli wrote: >>>> TCP sockets and UDP sockets have a different interface. Some >>>> messages >>>> can only be sent to TCP sockets others only to UDP sockets. Yet >>>> they are >>>> both represented by the same Socket class. >>> That sounds like a really easy and backward compatible refactoring >>> (add two subclasses, fix the constructors, and push down methods). >>> Why >>> don't you submit a patch? >> >> Yeah if it's as simple as that and it doesn't break any plugin or >> stuff. > > And we find a solution for SocksSocket which is of course a subclass > of > Socket. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Philippe Marschall-2-3
Philippe,
I've never had much use for UDP, but the common things should work the same, at least to a point. UDP is the protocol that does not guarantee packet order or even delivery, right? So anything remotely stream related is out, and there might be other things that should legitimately be different, if I'm thinking of the right thing. While I'm displaying ignorance, there is a negotiated rate serial protocol that ends up being implemented using sockets. I can't think of the name of it but know where to look for a reminder. It is something I would like to see supported "some day." Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Philippe Marschall Sent: Wednesday, August 26, 2009 11:46 AM To: [hidden email] Subject: Re: [Pharo-project] new socket API Btw, while we're at it: TCP sockets and UDP sockets have a different interface. Some messages can only be sent to TCP sockets others only to UDP sockets. Yet they are both represented by the same Socket class. Cheers Philippe Schwab,Wilhelm K wrote: > Stef, > > I am not sure exactly what should be next, but I do not think we can simply kick it back to squeak-dev any more than we can the GUI/IDE, streams, etc., as sockets are very important. I am slowly chipping away at things that are standing in the way of my first Pharo success story; the impact of sockets has been minimal, but that will change. When I get going, I will be looking carefully at how things behave when peers do not respond (only the calling thread should suffer). Dolphin's socket streams are nice; Pharo seems to lean toward a single read-write stream, which should be fine as long as it manages not to hobble the image when the wrong wire gets kicked. SSL via OpenSSL should be easy to use; that will be an interesting adventure, but it needs to happen. > > With all due respect to those who have disagreed, I'm still highly suspicious that the networking problems have far more to do with IPv6 vs. 4 than the OS. > > Bill > > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of > Stéphane Ducasse > Sent: Wednesday, August 26, 2009 7:21 AM > To: [hidden email] > Subject: Re: [Pharo-project] new socket API > > so what is the next step? > > stef > > On Aug 26, 2009, at 8:19 AM, Michael Rueger wrote: > >> Philippe Marschall wrote: >> >>> There's gotta be a better way to do this. >>> >>> The whole API with arrays where you have to know the index, >>> ByteArray objects, integer flags and so forth seems like a blast from the past. >> >> We could put some default behavior wrapper methods around this. >> But this is really a discussion for squeak-dev, as the IPv6 >> implementation originates from etoys/olpc. >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Schwab,Wilhelm K wrote:
> Philippe, > > I've never had much use for UDP, but the common things should work the same, at least to a point. UDP is cool. > UDP is the protocol that does not guarantee packet order or even delivery, right? Yes, and it's packet ("datagram") oriented while TCP is stream oriented. > So anything remotely stream related is out, and there might be other things that should legitimately be different, if I'm thinking of the right thing. Sure. That's why it's uncool to have one class for two things that are so vastly different. > While I'm displaying ignorance, there is a negotiated rate serial protocol that ends up being implemented using sockets. I can't think of the name of it but know where to look for a reminder. It is something I would like to see supported "some day." There is the "datagrams" protocol on Socket. That's probably what you want when you're working with UDP. Then there's stuff that doesn't work when you're on UDP and gives a cryptic error message like #connectTo:port: and there is stuff that might work in both cases (#getOption, #setOption:value:). You have no idea from looking at the class what you can use in which case and what not. Cheers PHilippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |