On Sun, Jan 26, 2020 at 04:04:38PM +0300, Danil Osipchuk wrote:
> in 2011 it was changed by 'ul' (I don't know whom the initials belong to)
'ul' is Levente Uzonyi (leves at caesar.elte.hu)
A bit of archeology. I could not find message sends quickly in
https://github.com/NikolaySuslov/croquet-squeak and in 5.2 squeak image.
Code by Johh MacIntosh of 2000 in squeak 5.2 is below, for the
primitiveOnlySupportsOneSemaphore=true it relies on #setPeer:port which in
turn does a linux syscal
As soon as you start listening on udp port every host having connectivity
will be able to send you a datagram which will hit a smalltalk handler. It
is a concern both from performance and security pov. You may be willing to
implement your own protocol suit on top of udp to have a tcp like endpoint
> On 26 Jan 2020, at 09:42, HilaireFernandes wrote:
>
> Sven Van Caekenberghe wrote
>> Sounds nice, and indeed a (more) fun way to teach programming.
>>
>> But I still fail to see why you have to filter incoming UDP packets on
>> their origin address.
>
> If third party software on the works
Hi Sven,
Sven Van Caekenberghe wrote
> Sounds nice, and indeed a (more) fun way to teach programming.
>
> But I still fail to see why you have to filter incoming UDP packets on
> their origin address.
If third party software on the workstation are connected to other network
services, don't you
> On 20 Jan 2020, at 17:39, HilaireFernandes wrote:
>
> It is indeed about *receiveDataInto:fromHost:port:* I am talking about.
>
> Its *fromHost* parameter is not of the same nature as the *toHost* parameter
> in the message *sendUDPData:toHost:port: *
> In the former it is expected a ByteA
It is indeed about *receiveDataInto:fromHost:port:* I am talking about.
Its *fromHost* parameter is not of the same nature as the *toHost* parameter
in the message *sendUDPData:toHost:port: *
In the former it is expected a ByteArray to work, in the later a
SocketAdress.
*About the context.
*Thi
I am confused, you talk about three different methods,
receiveDataInto:fromHost:port:
receiveUDPData:toHost:port:
sendUDPData... (unspecified)
which one do you want to change and how ?
In any case, as answered by the primitives, the address seems to be a byte
array.
So for filtering incoming p
IMHO, this method is usefull when you are connected to a networked service
(IP and PORT). It helps to filter the datagrams you are interested by.
Turning SocketAdress as ByteArray could help without the need to convert
each IP ByteArray instance, as I proposed. Not sure about the implication,
thou
Hi Hilaire,
Given the following comment:
Socket>>#primSocket: socketID receiveUDPDataInto: aStringOrByteArray
startingAt: startIndex count: count
"Receive data from the given socket into the given array starting at
the given index.
Return an Array containing the amount read, th
Hello,
I would like to discuss one point regarding this method. In my opinion its
parameter hostAddress is expected to be a SocketAdress, but the method
interprets it as a ByteArray. So in the code bellow, the returned result is
0, although the host responds a datagram:
server := NetNameResolver
11 matches
Mail list logo
