Socket.ReceiveFrom... EndPoint ?

  • Thread starter Thread starter Skybuck Flying
  • Start date Start date
S

Skybuck Flying

Hello,

I am trying to use System.Net.Sockets in Delphi 8 for .NET.

The Socket.ReceiveFrom method has a RemoteEP parameter.

The type of this RemoteEP parameter is a EndPoint class.

The EndPoint class is an abstract class.

( Should I have type: a abstract class or an abstract class ? ;) I would
prefer an abstract class :) )

I am starting to believe that this is a really extraordinary way of passing
parameters.

I am starting to believe that it actually uses inheritance to pass a
inherited class.

So I am starting to believe that ReceiveFrom will create a IPEndPoint and
pass it via a EndPoint parameter.

So that in the future the socket could also return a IPXEndPoint or
something like that.

Though I am not yet sure.

So my questions are:

1. Does Socket.ReceiveFrom create the RemoteEP instance ?

Looking at the examples I would say: no it does not !

2. Can this instance be of any inherited type ?

Possibly !

3. Does the programmer have to create the instance to pass to the RemoteEP
parameter ?

Looking at the examples I would say: yes !

4. If so what should the type be ?

EndPoint... try to use typecasts if possible.

5. If so how should the type be passed ? since typecasting does not seem to
work ?!

Unknown ?!

Seems like a little issue.

I think it would be better if ReceiveFrom would just create the instance or
something.

I am not sure yet :)

Typecasting like this doesn't work in delphi:

mBytesReceived := mSocket.ReceiveFrom( mReceiveBuffer,
EndPoint(mSourceIPEndPoint) );

Skybuck.
 
Seems like a little issue.
I think it would be better if ReceiveFrom would just create the instance or
something.
Click to expand...

Hmm.. normally that would have been a better design... buutttt designing it
like that
could create a performance issue... since lot's of these things would have
to be created.

So I am starting to see why I wants this parameter passed by reference :)
 
Ah,

I think I found a way to do it from looking at the examples.

Delphi even has the cleanest solution :)

mSourceEndPoint := mSourceIPEndPoint; // assign it to an abstract class
variable.

mBytesReceived := mSocket.ReceiveFrom( mReceiveBuffer, mSourceEndPoint );

I dont think the SourceEndPoint has to be created... it's just a place
holder I think...

Actually when you look at it... it's a bit weird...

Why not use a typecast, that would safe the need for an extra parameter...
hmmm.

Pretty wacky.... I know integer typecasts are possible...

Are class typecasts not allowed ?!?

Or is there some other reason why this source does not compile ?:

// typecast version
mBytesReceived := mSocket.ReceiveFrom( mReceiveBuffer,
EndPoint(mSourceIPEndPoint) );

Skybuck.
 
Actually the more I look at it... the weirder it is.

// assigning a descendant to it's ancestor is allowed.
ancestor := descendat;

// passing a descendant to it's ancestor via a var parameter is not allowed
?!?

// prototype:
function something( ancestor ) : integer;

// not allowed ???
something( descendent ) ;

Weird !?

Skybuck.
 
Another crazy example of exceptions.

I set Socket.Blocking to false.

When I call ReceiveFrom a Exception is raised with Error Code 10035.

Winsock Documentation for Error Code 10035: WSAEWOULDBLOCK
 
Well at least no exception is raised if data is ready to be received.

( If no data available it will raise the exception... a non blocking
operation
could not be completed immediatly )

Reminds me of the quake source :)

This error could easily be ignored...

What is this error code used for when using udp sockets ?

Skybuck.
 
Skybuck Flying said:
Well at least no exception is raised if data is ready to be received.

( If no data available it will raise the exception... a non blocking
operation
could not be completed immediatly )

Reminds me of the quake source :)
Click to expand...

Yes this code was ported from the quake source:

// wsa quake bullshit in comments
if ( (bytes = SOCKET_ERROR) {and (WSAGetLastError=WSAEWOULDBLOCK)} ) then
begin
bytes := 0;
result := false; exit;
end;

All SOCKET_ERRORS should return false... not just WSAEWOULDBLOCK :)

That's why I put the WSAEWOULDBLOCK check in comments :)

Skybuck.
 
Hmmm

mSourceIPEndPoint := IPEndPoint.Create( IPAddress.Any, 0 );
mSourceEndPoint := mSourceIPEndPoint; // SourceEndPoint is just a reference
to SourceIPEndPoint ???

mBytesReceived := mSocket.ReceiveFrom( mBuffer, mSourceEndPoint );

writeln('source address: ', mSourceEndPoint.ToString ); // works

writeln('source address: ',
IPEndPoint(mSourceEndPoint).Address.ToString ); // works
writeln('source port: ', IPEndPoint(mSourceEndPoint).Port.ToString ); //
works

writeln('source address: ', mSourceIPEndPoint.Address.ToString ); // does
not work. 0.0.0.0
writeln('source port: ', mSourceIPEndPoint.Port.ToString ); // does not
work 0

Those last two lines are quite surprising...

Why doesn't that work ?

Since I think SourceEndPoint is just a reference to SourceIPEndPoint...

So I think the real data is stored in SourceIPEndPoint ?

But apparently not ?

Really weird... not creating SourceIPEndPoint leads to exceptions... so it
is needed !

But when using it it's empty ??? weeeeiird.

Skybuck.
 
"Phil Frisbie said:
He is talking to himself, and I have learned to ignore him as much as I can ;)
Click to expand...

Skybuck is why god provides us with killfiles.

Alun.
~~~~

[Please don't email posters, if a Usenet response is appropriate.]
 
Alun Jones said:
can ;)

Skybuck is why god provides us with killfiles.

Alun.
Click to expand...

If you use outlook express you don't need kill files.

Outlook express will automatically delete old message.

DUH

Skybuck.
 
Jeremy Collins said:
Who are you talking to?
Click to expand...

It's log of my experience with .NET and Sockets.

I am hoping microsoft one day reads it and might improve on it or clearify
it

Did your brain not grasp that ?

P.S.:

Try it sometime ;)

Skybuck.
 
Back
Top