Question regarding DatagramSocket...

Hi all,

I am trying to implement a script to relay UDP messages and have
encountered some problems with it.

1.) DatagramSocket local: '0.0.0.0' port: 23000 will end with an
exception... The document claims that local can be either a string or an
ip...and it fails here:

        addressClass := ipAddress isNil
                    ifTrue: [addressClass]
                    ifFalse: [ipAddress class].

so addressClass will be set to String, and later on "String newSocket"
leads to a messageNotUnderstood...

I have a patch to move the ipAddressOrString code to a method and call
it for the ipAddressOrString and the ipAddress variable. Would we need
this idiom in ServerSocket, StreamSocket as well? I will send a patch later.

2.) I am using the DatagramSocket>>next selector to receive the
datagram, I had to increase the default buffersize... but now all
(Datagram>>data)>>size return the size. I looked down into
AbstrackSocketImpl.st and the receive does not check the return value of
TCPrecvfrom at all. I have added a dataSize to Datagram and set the
return value there...

3.) Sometimes I see a nil Datagram being returned while I see genuine
traffic with tcpdump... but I will have to trace that part.



do the changes in 1st and 2nd make sense?

        z.

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/11/2010 01:25 PM, Holger Hans Peter Freyther wrote:
Hard to say without seeing the patch. :-)

> 2.) I am using the DatagramSocket>>next selector to receive the
> datagram, I had to increase the default buffersize... but now all
> (Datagram>>data)>>size return the size. I looked down into
> AbstrackSocketImpl.st and the receive does not check the return value of
> TCPrecvfrom at all. I have added a dataSize to Datagram and set the
> return value there...

Looks fine.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/11/2010 08:29 PM, Paolo Bonzini wrote:

>
> Hard to say without seeing the patch. :-)

This is Work In Progress so there is no ChangeLog entry.

The change in Sockets.st is to make:

    Sockets.DatagramSocket local: '0.0.0.0' port: 23000

Somehow using '23.0.0.0' will not throw an exception, and the bind fails
but no exception is thrown as well (it bound to 0.0.0.0:0). There is at
least another bug, I should create the localAddr first and then try to
derive the addressClass from that or create a local bind.



>
>> 2.) I am using the DatagramSocket>>next selector to receive the
>> datagram, I had to increase the default buffersize... but now all
>> (Datagram>>data)>>size return the size. I looked down into
>> AbstrackSocketImpl.st and the receive does not check the return value of
>> TCPrecvfrom at all. I have added a dataSize to Datagram and set the
>> return value there...

The second part is to introduce two new selectors to Datagram. One is
#dataSize the other is #dataSize, the Socket Impl. will set the return
value of the TCPrecvfrom as dataSize. This way a caller can find out how
big a datagram was, on the sending side I only want to send as much data
as I have received, so I introduced a #payloadSize which decides how
much of data to send. If dataSize is not set (or reset) it will fallback
to data size.


so how does that look?

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/11/2010 05:16 PM, Holger Hans Peter Freyther wrote:
> +    payloadSize [
> + <comment: 'I determine the payload size.'>
> +        <category: 'accessing'>
> +        dataSize isNil
> +    ifTrue: [^data size]
> +    ifFalse: [^dataSize]
> +    ]

Just name it "size" please.  There is no <comment: ''> pragma in
methods.  Finally, please put a single ^ outside the if blocks.

However, this part is good to commit for 3.2.1.

This should go to a (very high) superclass as you suspected.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/11/2010 11:33 PM, Paolo Bonzini wrote:

> Just name it "size" please.  There is no <comment: ''> pragma in
> methods.  Finally, please put a single ^ outside the if blocks.

So no return from within the if? What is the reasoning? What would be
preferred, assign to a local variable and then return, or put the return
before the object ifNil check?



>
> This should go to a (very high) superclass as you suspected.

I picked the AbstractSocket class... maybe we should even move it into
SocketAddr?

I have three patches attached to carry out these changes. Looking for
comments.



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

>> Just name it "size" please.  There is no <comment: ''> pragma in
>> methods.  Finally, please put a single ^ outside the if blocks.
>
> So no return from within the if? What is the reasoning? What would be
> preferred, assign to a local variable and then return, or put the return
> before the object ifNil check?

Answering both question with a citation from "Smalltalk Best Practice Patterns":

Assignment and return are often found in both branches of a
conditional. Look for opportunities to factor both to the outside of
the conditional. Here is an example of a return on both branches of a
conditional:

    cost
        self isInitialized
            ifTrue: [^self calculateCost]
            ifFalse: [^0]

If I write code like this, I don’t mean “here are two alternative
paths of execution,”, I mean, “here are two alternative values to be
returned.” Thus, a Conditional Expression expresses my intent more
clearly:

    cost
        ^self isInitialized
            ifTrue: [self calculateCost]
            ifFalse: [0]

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/12/2010 04:30 PM, Paolo Bonzini wrote:

>
> Answering both question with a citation from "Smalltalk Best Practice Patterns":

Is that available somewhere or do you have the ISBN Number?


> If I write code like this, I don’t mean “here are two alternative
> paths of execution,”, I mean, “here are two alternative values to be
> returned.” Thus, a Conditional Expression expresses my intent more
> clearly:
>

Would something like the attached patch work for it?

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, 16 Jun 2010 20:33:36 +0800
Holger Hans Peter Freyther <[hidden email]> wrote:

> On 06/12/2010 04:30 PM, Paolo Bonzini wrote:
>
> >
> > Answering both question with a citation from "Smalltalk Best Practice Patterns":
>
> Is that available somewhere or do you have the ISBN Number?

http://www.bookzilla.de/shop/action/productDetails/3624787/kent_beck_smalltalk_best_practice_patterns_013476904X.html

s.

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 06/16/2010 02:33 PM, Holger Hans Peter Freyther wrote:
> On 06/12/2010 04:30 PM, Paolo Bonzini wrote:
>
>>
>> Answering both question with a citation from "Smalltalk Best Practice Patterns":
>
> Is that available somewhere or do you have the ISBN Number?

Amazon says 978-0134769042.

>> If I write code like this, I don’t mean “here are two alternative
>> paths of execution,”, I mean, “here are two alternative values to be
>> returned.” Thus, a Conditional Expression expresses my intent more
>> clearly:
>
> Would something like the attached patch work for it?

Yes, that would be it.  However, I'm not sure about the benefit of
complicating the logic of the #ifTrue: block.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk