Hi,

Yes, this is possible that the code is suffering from the native API
issue.  I don't have a copy of the 1.6.2 code installed, so...

Erich, if TIPC 1.6.2 has the following code in
port.c:port_dispatcher_sigh()
                case TIPC_CONN_MSG:{
                                tipc_conn_msg_event cb =
up_ptr->conn_msg_cb;
                                u32 peer_port = port_peerport(p_ptr);
                                u32 peer_node = port_peernode(p_ptr);

                                spin_unlock_bh(p_ptr->publ.lock);
                                if (unlikely(!connected)) {
                                        if (unlikely(published))
                                                goto reject;
                                        tipc_connect2port(dref,&orig);
                                }
                                if (unlikely(msg_origport(msg) !=
peer_port))
                                        goto reject;
                                if (unlikely(msg_orignode(msg) !=
peer_node))
                                        goto reject;

Then you have the problem that was found trying to establish a
connection with the Native API.  You would be best off upgrading to TIPC
1.7.5.  A very quick *TEST* would be to change the checks to what is
below; if it allows the connection to be established with the topology
server, then upgrade to TIPC 1.7.5 (don't just apply this change since
there are a number of other changes required for a real fix).

                case TIPC_CONN_MSG:{
                                tipc_conn_msg_event cb =
up_ptr->conn_msg_cb;
                                u32 peer_port = port_peerport(p_ptr);
                                u32 peer_node = port_peernode(p_ptr);

                                spin_unlock_bh(p_ptr->publ.lock);
                                if (unlikely(!connected)) {
                                        if (tipc_connect2port(dref,
&orig))
                                                goto reject;
                                } else if (unlikely(
                                            (msg_origport(msg) !=
peer_port) ||
                                            (msg_orignode(msg) !=
peer_node)))
                                        goto reject;

Elmer

-----Original Message-----
From: Stephens, Allan 
Sent: Monday, February 25, 2008 9:15 AM
To: [EMAIL PROTECTED]; Horvath, Elmer
Cc: tipc-discussion@lists.sourceforge.net
Subject: RE: [tipc-discussion] port name -> port_id ?

Hi guys:

Since Erich is using TIPC 1.6.2, I wonder if he's running into a native
API problem Elmer discovered and which is fixed in TIPC 1.7.5.  I think
it had something to do with a check being done incorrectly during
connection setup.  (Does this ring a bell, Elmer?)

Erich, is it possible for you to upgrade to TIPC 1.7.5?

-- Al

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Erich Focht
Sent: Saturday, February 23, 2008 4:12 PM
To: Horvath, Elmer
Cc: tipc-discussion@lists.sourceforge.net
Subject: Re: [tipc-discussion] port name -> port_id ?

Hello,

by the way, I added a conn_error_callback, as in your code.
Interestingly:
after sending the empty tipc_send2name the conn_error_cb gets invoked
with reason=2. The tipc_send fails and returns something like -22 or
-28, so I let the module loading fail.

If instead I send directly the subscription message with tipc_send2name
(without sending an empty message first), the conn_error_cb gets called
when the first publish event should be comming.

Regards,
Erich


On Samstag 23 Februar 2008, Erich Focht wrote:
> Dear Elmer,
> 
> thanks for the example. I actually added your callback to my init 
> code, and changed the subscription "type" to 18888, such that the 
> example should work fine with the tipc_demo-1.16/topology_subscr_demo/
example.
> 
> But it doesn't (2.6.24, on x86_64). Loading the module shows the 
> messages are sent fine, and a new connection is in the "tipc-config
-p" output:
> 2818850801: connected to <1.1.178:2818850799>
> 
> But when I start the user-space subscriptions monitor from the 
> topology_subscr_demo the ports output shows something like:
> 2818850753: connected to <1.1.178:2818850751> via {1,1}
> 2818850751: connected to <1.1.178:2818850753>
> 
> So I'm missing one of the connections.
> 
> The user-space subscription monitor is reporting correctly 
> publish/withdraw events, e.g. when starting server_tipc from the demo.
> This tells me that either I'm doing something really wrong, or 
> something is broken with the native interface in 2.6.24. If you want 
> to try reproducing, the source is attached.
> 
> Best regards,
> Erich
> 



------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Reply via email to