Error: cannot handle extended pids and ports

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Joel Reymont-2
My archive search is still going (takes a few minutes for some reason)
but I have stumbled twice now across this error:

=ERROR REPORT==== 1-Apr-2005::19:01:41 ===
** enode1: Connection attempt to node
py_interface_test aborted since it cannot handle extended pids
and ports. **

Same error applies to Distel 3.3.

I'm using R10B3 on Mac OSX which comes with erl_interface-3.5.1.

    Thanks, Joel

--
http://wagerlabs.com/tech




Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Luke Gorrie-3
"Joel Reymont" <joelr1> writes:

> My archive search is still going (takes a few minutes for some reason)
> but I have stumbled twice now across this error:
>
> =ERROR REPORT==== 1-Apr-2005::19:01:41 ===
> ** enode1: Connection attempt to node
> py_interface_test aborted since it cannot handle extended pids
> and ports. **
>
> Same error applies to Distel 3.3.

Some feature-negotiation takes place during the distributed Erlang
handshake and R10B demands more support than previous versions.

The version of Distel in the Jungerl (sourceforge project 'jungerl')
should work. Exerpt from Distel changelog:

        * elisp/derl.el (derl-send-name): Lie to Erlang by saying that we
        support extended PIDs. This way we can establish distribution with
        R10B-0, which doesn't seem to actually send extended pids
        initially. (This is a lame workaround but I'm in a hurry and the
        extended-pid format is not documented.)

You could try this totally untested patch to py_interface to do the
same thing:

--- erl_opts.py.orig    2005-04-01 20:42:02.000000000 +0200
+++ erl_opts.py 2005-04-01 20:43:02.000000000 +0200
@@ -32,6 +32,7 @@
 DISTR_FLAG_DISTMONITORNAME = 32;
 DISTR_FLAG_HIDDENATOMCACHE = 64;
 DISTR_FLAG_NEWFUNTAGS = 128;
+DISTR_FLAG_EXTENDEDPIDSPORTS = 256;

 class ErlNodeOpts:
     def __init__(self,
@@ -39,7 +40,7 @@
                  shortNodeNames=1,
                  cookie="",
                  distrVersion=5,
-                 distrFlags=DISTR_FLAG_EXTENDEDREFERENCES
+                 distrFlags=DISTR_FLAG_EXTENDEDREFERENCES|DISTR_FLAG_EXTENDEDP\
IDSPORTS
                  ):
         self._netTickTime = netTickTime
         self._shortNodeNames = shortNodeNames



Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Joel Reymont-2
> Luke Gorrie wrote:
>You could try this totally untested patch to py_interface to do the
>same thing:

Thank you Luke!

Now, you wouldn't have a totally untested Reliable UDP implementation
lying around, would you? :)

    Joel

--
http://wagerlabs.com/tech




Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Luke Gorrie-3
"Joel Reymont" <joelr1> writes:

> > Luke Gorrie wrote:
> >You could try this totally untested patch to py_interface to do the
> >same thing:
>
> Thank you Luke!
>
> Now, you wouldn't have a totally untested Reliable UDP implementation
> lying around, would you? :)

I'd suggest starting simple, either with TCP or UDP with fingers
crossed (unlikely to lose packets in laboratory conditions), and then
think some more once you see how the protocol turns out. RUDP looks
pretty TCP'ishly complex and I can imagine a much simpler protocol if
e.g. it turns out that each side only needs to send one packet at a
time.

My colleagues could probably give you some good tips on how far you
can make TCP scale in Erlang, I suspect it's a pretty long way..

I do have a mostly untested/unfinished user-space TCP if you want, but
that would take you back to lisp and I don't remember where the latest
sources are :-) http://www.cliki.net/Slitch and Tobbe has written a
more complete one in Erlang (old and may need slight forwards-porting)
http://www.bluetail.com/tobbe/etcp/

Practical path would be to ignore those links though :-)




Reply | Threaded
Open this post in threaded view
|

Scaling TCP (was Re: Error: cannot handle extended pids and ports)

Joel Reymont-2
> Luke Gorrie wrote:

>My colleagues could probably give you some good tips on how far you
>can make TCP scale in Erlang, I suspect it's a pretty long way..

I must have taken Vance's suggestion the wrong way. He stated that Erlang
can only handle about 255 nodes and that I should use RUDP.

255 nodes does not mean 255 TCP clients, I suppose, so I can first try
TCP and switch to RUDP later on and if needed.

    Thanks, Joel

--
http://wagerlabs.com/tech




Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Vance Shipley-2
In reply to this post by Luke Gorrie-3

You could also try starting the emulator with a +R option to
specify an older release.

        -Vance

On Fri, Apr 01, 2005 at 08:51:36PM +0200, Luke Gorrie wrote:
}  
}  Some feature-negotiation takes place during the distributed Erlang
}  handshake and R10B demands more support than previous versions.


Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Vance Shipley-2
In reply to this post by Luke Gorrie-3
"Joel Reymont" <joelr1> writes:
}
} Now, you wouldn't have a totally untested Reliable UDP implementation
} lying around, would you? :)


Since RUDP has been superceded by SCTP that leads us back to the gen_sctp
discussion.  :)

SCTP isn't really the answer for you as although the server side is easy
to provision getting SCTP support into clients is unlikely for many years.

I wouldn't try and implement a full blown RUDP in erlang.  I'm sure you
can build an application specific protocol on top of UDP fairly easily
which would satisfy your requirements.  Stevens(*) has a section entitled
"Adding reliability to UDP applications" which you might want to read.
As he points out many existing applications have implemented this; DNS,
SNMP, TFTP & RPC are given as examples.

        -Vance

(*) http://www.kohala.com/start/unpv12e.html


Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Joel Reymont-2
> Vance Shipley wrote:

>Since RUDP has been superceded by SCTP that leads us back to the gen_sctp
>discussion.  :)

Funny, I was just reading up on SCTP.

>SCTP isn't really the answer for you as although the server side is easy
>to provision getting SCTP support into clients is unlikely for many years.

Why is that? Can't I just build a SCTP client?

    Joel

--
http://wagerlabs.com/tech




Rob
Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Rob
In reply to this post by Vance Shipley-2
What about using spread? http://www.spread.org/ there is a python binding and I thought there was/is an erlang binding.

You could have various levels of readonly multicast data streams,
that a process could subscribe to and you could even create an api that allowed others to build apps that plug in to a given public feed.

* public info about server status, active games, player stats, rankings, etc (the lobby server/[service] you talk about on your site)
* public info about game X (watch game)
* public info about player Y (watch all games for a certain player, I don't know if current poker servers have this function)
* player-only info about game X (participate in game)
* server-to-server only info about games, internal server states etc.

As new servers, processes or clients start up they would either subscribe to the appropriate streams or create new ones and register
them with a stream directory service.
For poker it seems very little info is transfered upstream so those could probably be tcp connected per request - so placing a bet or
getting cards, etc would be an atomic tcp interaction. Even a single erlang node should be able to handle 10's or 100's of 1,000's of
player upstream interactions that way.

Vance Shipley wrote:

> "Joel Reymont" <joelr1> writes:
> }
> } Now, you wouldn't have a totally untested Reliable UDP implementation
> } lying around, would you? :)
>
>
> Since RUDP has been superceded by SCTP that leads us back to the gen_sctp
> discussion.  :)
>
> SCTP isn't really the answer for you as although the server side is easy
> to provision getting SCTP support into clients is unlikely for many years.
>
> I wouldn't try and implement a full blown RUDP in erlang.  I'm sure you
> can build an application specific protocol on top of UDP fairly easily
> which would satisfy your requirements.  Stevens(*) has a section entitled
> "Adding reliability to UDP applications" which you might want to read.
> As he points out many existing applications have implemented this; DNS,
> SNMP, TFTP & RPC are given as examples.
>
> -Vance
>
> (*) http://www.kohala.com/start/unpv12e.html


Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Sean Hinde-2
In reply to this post by Joel Reymont-2

On 1 Apr 2005, at 21:52, Joel Reymont wrote:

>> Vance Shipley wrote:
>
>> Since RUDP has been superceded by SCTP that leads us back to the
>> gen_sctp
>> discussion.  :)
>
> Funny, I was just reading up on SCTP.
>
>> SCTP isn't really the answer for you as although the server side is
>> easy
>> to provision getting SCTP support into clients is unlikely for many
>> years.
>
> Why is that? Can't I just build a SCTP client?

It is a very heavy duty replacement for TCP running over raw IP. There
is an implementation in the Linux 2.6 kernels if you fancy playing with
it.

Not that I wish to discourage you if you fancy having a go. I did once
start to write a version of it in Erlang running over UDP (it was an
option in the spec, I don't know if it still is), but as with many such
things it was much bigger than available time and skills permitted :-)

Sean



Rob
Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Rob
In reply to this post by Vance Shipley-2
This didn't seem to arrive at the list, retrying = sorry if it gets duped...

What about using spread? http://www.spread.org/ there is a python binding and I thought there was/is an erlang binding.

You could have various levels of readonly multicast data streams,
that a process could subscribe to and you could even create an api that allowed others to build apps that plug in to a given public feed.

* public info about server status, active games, player stats, rankings, etc (the lobby server/[service] you talk about on your site)
* public info about game X (watch game)
* public info about player Y (watch all games for a certain player, I don't know if current poker servers have this function)
* player-only info about game X (participate in game)
* server-to-server only info about games, internal server states etc.

As new servers, processes or clients start up they would either subscribe to the appropriate streams or create new ones and register
them with a stream directory service.
For poker it seems very little info is transfered upstream so those could probably be tcp connected per request - so placing a bet or
getting cards, etc would be an atomic tcp interaction. Even a single erlang node should be able to handle 10's or 100's of 1,000's of
player upstream interactions that way.

Vance Shipley wrote:

> "Joel Reymont" <joelr1> writes:
> }
> } Now, you wouldn't have a totally untested Reliable UDP implementation
> } lying around, would you? :)
>
>
> Since RUDP has been superceded by SCTP that leads us back to the gen_sctp
> discussion.  :)
>
> SCTP isn't really the answer for you as although the server side is easy
> to provision getting SCTP support into clients is unlikely for many years.
>
> I wouldn't try and implement a full blown RUDP in erlang.  I'm sure you
> can build an application specific protocol on top of UDP fairly easily
> which would satisfy your requirements.  Stevens(*) has a section entitled
> "Adding reliability to UDP applications" which you might want to read.
> As he points out many existing applications have implemented this; DNS,
> SNMP, TFTP & RPC are given as examples.
>
> -Vance
>
> (*) http://www.kohala.com/start/unpv12e.html


Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Vance Shipley-2
In reply to this post by Joel Reymont-2
On Fri, Apr 01, 2005 at 09:52:09PM +0100, Joel Reymont wrote:
}  
}  Why is that? Can't I just build a SCTP client?


"Just".  A software developers favourite word.  :)

I assume you want to get around to playing poker at some point.
SCTP is a very complex beast which provides much more than RUDP
does.  It belongs in the kernel too.

Now if you want something to do you could build us a gen_sctp
module which interfaced with the, now standardized, SCTP API
available with Solaris 10 and other OSes.  That would be nice.

        -Vance



Reply | Threaded
Open this post in threaded view
|

Error: cannot handle extended pids and ports

Joel Reymont-2
> Vance Shipley wrote:

>I assume you want to get around to playing poker at some point.
>SCTP is a very complex beast which provides much more than RUDP
>does.  It belongs in the kernel too.

I did not realize it was a kernel-level protocol.

>Now if you want something to do you could build us a gen_sctp
>module which interfaced with the, now standardized, SCTP API
>available with Solaris 10 and other OSes.  That would be nice.

I think I have my hands full as it is, having blown my last deadline and
needing to rewrite the poker engine in Erlang :-).

    Cheers, Joel

--
http://wagerlabs.com/tech




Reply | Threaded
Open this post in threaded view
|

Scaling TCP (was Re: Error: cannot handle extended pids and ports)

Mickael Remond-2
In reply to this post by Joel Reymont-2
Joel Reymont wrote:

>>Luke Gorrie wrote:
>
>
>>My colleagues could probably give you some good tips on how far you
>>can make TCP scale in Erlang, I suspect it's a pretty long way..
>
>
> I must have taken Vance's suggestion the wrong way. He stated that Erlang
> can only handle about 255 nodes and that I should use RUDP.
>
> 255 nodes does not mean 255 TCP clients, I suppose, so I can first try
> TCP and switch to RUDP later on and if needed.

The 255 nodes figures was stated in the case you were planning to use
Erlang node distribution protocol. TCP client can scale a lot more.
A nice example of the scalability is the Yaws vs Apache benchmark:

http://www.sics.se/~joe/apachevsyaws.html

Yaws (Erlang Web server) were able to handle 80000 simultaneous users
connected.

--
Micka?l R?mond