[Pharo-project] new socket API
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
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
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 Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, August 26, 2009 7:21 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, August 26, 2009 7:21 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, August 26, 2009 7:21 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Philippe Marschall Sent: Wednesday, August 26, 2009 11:46 AM To: pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, August 26, 2009 7:21 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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
participants (5)
-
Lukas Renggli -
Michael Rueger -
Philippe Marschall -
Schwab,Wilhelm K -
Stéphane Ducasse