Bugs item #1732039, was opened at 2007-06-06 16:31
Message generated for change (Comment added) made by vkc1974
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1732039&group_id=139143
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: ver 1.2.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kovalevich Victor (vkc1974)
Assigned to: Nobody/Anonymous (nobody)
Summary: tcp_send() routine tries to connect to UA
Initial Comment:
int tcp_send(struct socket_info* send_sock, int type, char* buf, unsigned len,
union sockaddr_union* to, int id) (tcp_main.c:680) tries to restore TCP
connection with UA site if there are no valid and actual connections in USRLOC.
Is good behavior?
This operation is senseless especially in the case of an UA working behind a
NAT. Furthermore this operation blocks openser service for a while and
eventually causes it to be unavailable.
----------------------------------------------------------------------
>Comment By: Kovalevich Victor (vkc1974)
Date: 2007-06-07 14:50
Message:
Logged In: YES
user_id=490489
Originator: YES
Discussed situation is occurred while NOTIFY request is sent to a UA site
(coursed by PUBLISH request processing) but there is no valid (not
expired!) contact (connection) for UA site NOTIFY message is going to be
sent to.
A dialog instance is created while appropriate SUBSCRIBE request is
processed. So that all NOTIFY requests related to given subscribe are sent
within given dialog. There is a tree of calls how NOTIFY request is sent:
notify()
req_within()
send_pr_buffer()
msg_send()
tcp_send()
tcpconn_get() routine is called within tcp_send() to look for actual
connection instance - it returns NULL (existed connection to appropriate UA
site has expired and cannot be considered as actual one). So that flags
field of a connection instance (struct tcp_connection) is not accessible to
be analyzed. So that new connection is tried to be established via
tcpconn_connect() that blocks openser service and makes it unavailable to
process new request!
This scenario takes place in both cases UDP/TCP or TLS/TCP (secure
communication) transport protocols are used. In the first case this
described block an denied of service situation can be avoided as udp_send()
routine does not try to establish new communication to UA site a request is
going to be sent. In the second case (TLS/TCP transport)
given situation tcp_send() routine is used only.
Really I am surprised why openser tries to establish new TCP
communication. In my point of view there is very bad way to try do it every
time no valid TCP communication to send a request/answer is available (the
better way could be to try to establish new communication once or twice and
no to try it again and again).
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-06-06 20:35
Message:
Logged In: NO
regarding initial request, if standard nat flag is set, it makes no sense
try to establish tcp session.
regarding in-dialog request, a custom flag could be used.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-06-06 20:26
Message:
Logged In: NO
Hi Victor!
Funny - at the same time of your report we dicussed this topic on the
openser programming course.
Yes - there should be an option to avoid TCP connection establishment to
clients behind NAT. Some ideas were to:
- no TCP connection establishment attempt if nat flag is set
- no TCP connection establishment attempt after lookup()
- no TCP connection establishment attempt if a certain flag is set
For in-dilalog it is not that easy to distinguish between destination to
which a connection establishment should be done (gateway, proxy) and to
others (user agents)
Klaus
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1732039&group_id=139143
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
