On Thu, Oct 08, 2015 at 10:48:07AM +0200, Holger Freyther wrote:
On 07 Oct 2015, at 16:18, Neels Hofmeyr
<nhofmeyr(a)sysmocom.de> wrote:
+/* TODO move to osmocom/core/socket.c ? */
where did you take this from?
basically the beginning of osmo_sock_init()
+/* TODO move
to osmocom/core/socket.c ? */
+int osmo_sockaddr_init(struct sockaddr_storage
*addr, socklen_t *addr_len,
+ uint16_t family, uint16_t type, uint8_t proto,
+ const char *host, uint16_t port)
+{
ah yeah. the by hostname is a good idea. But this should only be used at the
beginning of an application as we don't want to block on a DNS query.
In fact, I use this function to hardcode the GTP server. We will in future
fetch the GTP server by DNS, and I'm not entirely clear on whether
getaddrinfo() can resolve that. If we need a full res_query() instead, the
gtphub will no longer need this function, and its use is reduced to a
courtesy to future API users...
+static struct
log_info_cat gtphub_categories[] = {
+static const struct log_info gtphub_log_info =
{
+ .filter_fn = gtphub_log_filter_fn,
+ .cat = gtphub_categories,
+ .num_cat = ARRAY_SIZE(gtphub_categories),
+};
nothing else will be used as debug log? Depending on the answer it might be
better to just always initialize the GTPHUB area..
I don't fully see thru the debug setup yet. Other binaries around seem to
re-create very similar category lists, apparently just listing all that is
defined. I tried to find the minimum first. Others may be added as needed.
What do you mean by
better to just always initialize the GTPHUB area..
? IIUC that's what the patch is doing right now?
If you use recvmsg then the msg_flags will have
MSG_TRUNC set or not.
Not sure if you want to use it.
I'll put a TODO comment there. The 4kb buf should suffice for now. Thanks
for the hint! Wasn't aware.
+ rc =
osmo_sock_init_ofd(&clients_ofd, AF_UNSPEC, SOCK_DGRAM, IPPROTO_UDP, clients_addr_str,
clients_port, OSMO_SOCK_F_BIND);
+ rc = osmo_sock_init_ofd(&server_ofd, AF_UNSPEC, SOCK_DGRAM, IPPROTO_UDP,
server_rx_addr_str, server_rx_port, OSMO_SOCK_F_BIND);
Who is the server? who is the client? Maybe give it names to what we expect on the side?
One is the SGSN, the other is the GGSN?
I thought of a GTP server == GGSN and GTP client == SGSN. If that's
ambiguous at all I'll be happy to change it, e.g. to to_sgsns, to_ggsns.
[SGSN] <---> [to_sgsns GTPHUB to_ggsns] <---> [GGSN]
With the "to_" prefix to avoid this ambiguity: if the SGSN contacts the
gtphub, the gtphub looks like a GGSN, so a confused reader could think of
the "to_sgsns" port as a GGSN. Or rather a "from_" prefix? :P
~Neels