Miroirs/xwords
1
0
Fork 0
mirror of git://xwords.git.sourceforge.net/gitroot/xwords/xwords synced 2025-01-23 07:27:22 +01:00
Code Issues Projects Releases Packages Wiki Activity
xwords/xwords4/common/device.h

71 lines
3 KiB
C
Raw Normal View History

add new files device{c,h} I've long wanted common code and state that outlast a single game. The smsproto stuff is a step in that direction, but this file will be a place for anything new. Starting, perhaps, with a mapping of deviceID -> addressInfo (e.g. BT name or SMS number of opponent device) that will let me stop duplicating that stuff in every game's comms state. We'll see. It's guarded by a compile-time flag so I can play with in on the Linux version until ready.
2020-01-08 10:19:01 -08:00
/* -*-mode: C; fill-column: 78; c-basic-offset: 4; -*- */
/*
* Copyright 2020 by Eric House (xwords@eehouse.org). All rights reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
#ifndef _DEVICE_H_
#define _DEVICE_H_
#include "dutil.h"
// void device_load( XW_DUtilCtxt dctxt );
# ifdef XWFEATURE_DEVICE
add mqtt as a new transport This is meant to replace the relay eventually, but for now it's a new option, like BT or SMS, to be chosen. Protocol is handled in common/ code for the first time, meaning that linux and android interact without the need to keep two platforms in sync. Linux uses lib-mosquitto, and Android uses eclipse's Paho client (the generic java version, not the one that uses four-year-old Service patterns and so crashes for SDK >= 26.)
2020-05-20 13:58:53 -07:00
void dvc_store( XW_DUtilCtxt* dctxt, XWEnv xwe );
add new files device{c,h} I've long wanted common code and state that outlast a single game. The smsproto stuff is a step in that direction, but this file will be a place for anything new. Starting, perhaps, with a mapping of deviceID -> addressInfo (e.g. BT name or SMS number of opponent device) that will let me stop duplicating that stuff in every game's comms state. We'll see. It's guarded by a compile-time flag so I can play with in on the Linux version until ready.
2020-01-08 10:19:01 -08:00
# else
add mqtt as a new transport This is meant to replace the relay eventually, but for now it's a new option, like BT or SMS, to be chosen. Protocol is handled in common/ code for the first time, meaning that linux and android interact without the need to keep two platforms in sync. Linux uses lib-mosquitto, and Android uses eclipse's Paho client (the generic java version, not the one that uses four-year-old Service patterns and so crashes for SDK >= 26.)
2020-05-20 13:58:53 -07:00
# define dvc_store(dctxt, xwe)
add new files device{c,h} I've long wanted common code and state that outlast a single game. The smsproto stuff is a step in that direction, but this file will be a place for anything new. Starting, perhaps, with a mapping of deviceID -> addressInfo (e.g. BT name or SMS number of opponent device) that will let me stop duplicating that stuff in every game's comms state. We'll see. It's guarded by a compile-time flag so I can play with in on the Linux version until ready.
2020-01-08 10:19:01 -08:00
# endif
invitations work on linux
2022-12-20 09:20:02 -08:00
typedef void (*MsgAndTopicProc)( void* closure, const XP_UCHAR* topic,
API cleanup and all done This should complete sending to multiple topics (for backwards compatibility) and supporting combined messages in the future (sending them is hard; receiving not so much.)
2022-12-20 11:55:30 -08:00
const XP_U8* msgBuf, XP_U16 msgLen );
invitations work on linux
2022-12-20 09:20:02 -08:00
add mqtt as a new transport This is meant to replace the relay eventually, but for now it's a new option, like BT or SMS, to be chosen. Protocol is handled in common/ code for the first time, meaning that linux and android interact without the need to keep two platforms in sync. Linux uses lib-mosquitto, and Android uses eclipse's Paho client (the generic java version, not the one that uses four-year-old Service patterns and so crashes for SDK >= 26.)
2020-05-20 13:58:53 -07:00
void dvc_getMQTTDevID( XW_DUtilCtxt* dutil, XWEnv xwe, MQTTDevID* devID );
add dbg-only menuitem to set mqtt devid
2023-04-26 13:57:21 -07:00
void dvc_setMQTTDevID( XW_DUtilCtxt* dutil, XWEnv xwe, const MQTTDevID* devID );
generate new mqtt devid when server reports dupe Thanks to my use of unseeded() rand() early on to generate mqtt device IDs, a handful of devices are using the same devIDs. The server notices this and passes a new response which triggers generating a new id that should be unique (rand() being seeded earlier now.) Testing says the games that are left behind with the old devid will limp along thanks to their relay connection while newer games will be better.
2020-09-13 14:48:36 -07:00
void dvc_resetMQTTDevID( XW_DUtilCtxt* dutil, XWEnv xwe );
use persist flag and new per-game mqtt topics (too) I didn't understand MQTT at all. Per the docs anyway it only keeps a message around if its "persist" flag is set, and then it only keeps the most recent per topic. I expected that when a device connected, messages would be waiting for it, but that's apparently not true (some evidence to the contrary.) But having all games on a device share the same topic means only one message can be waiting. So switch to including gameID in the topic, subscribing to a wildcard topic and sending to a different one per game. For now, for legacy purposes, we'll keep sending to the old per-device topic.
2022-12-16 13:33:36 -08:00
void dvc_getMQTTSubTopics( XW_DUtilCtxt* dutil, XWEnv xwe,
XP_UCHAR* storage, XP_U16 storageLen,
XP_U16* nTopics, XP_UCHAR* topics[] );
invitations work on linux
2022-12-20 09:20:02 -08:00
void dvc_makeMQTTInvites( XW_DUtilCtxt* dutil, XWEnv xwe,
MsgAndTopicProc proc, void* closure,
const MQTTDevID* addressee,
remove timestamps from mqtt header and procs that feed it It belongs in comms msg header. Also remove PROTO_2, which shipping code can read but never could send.
2022-12-30 15:33:51 -08:00
const NetLaunchInfo* nli );
Once received, nuke invite on mqtt broker To prevent deleted games' ghost invitations from remaining as persisted on a topic and so being received over and over, have recipient of invitation send an empty message on the same topic to remove them. Any message sent once the game start would have replaced the invitation, but sometimes if the sender is deleted at the right time there's none.
2023-01-24 17:23:30 -08:00
void dvc_makeMQTTNukeInvite( XW_DUtilCtxt* dutil, XWEnv xwe,
MsgAndTopicProc proc, void* closure,
const NetLaunchInfo* nli );
snapshot: new mqtt msg format allowing multiple messages
2022-12-19 19:53:57 -08:00
toward changing APIs to allow combined messages for mqtt
2023-03-17 19:21:57 -07:00
XP_S16 dvc_makeMQTTMessages( XW_DUtilCtxt* dutil, XWEnv xwe,
MsgAndTopicProc proc, void* closure,
change send method to take list instead of array
2023-03-18 15:31:20 -07:00
const SendMsgsPacket* const msgs,
toward changing APIs to allow combined messages for mqtt
2023-03-17 19:21:57 -07:00
const MQTTDevID* addressee, XP_U32 gameID,
XP_U16 streamVersion );
API cleanup and all done This should complete sending to multiple topics (for backwards compatibility) and supporting combined messages in the future (sending them is hard; receiving not so much.)
2022-12-20 11:55:30 -08:00
void dvc_makeMQTTNoSuchGames( XW_DUtilCtxt* dutil, XWEnv xwe,
compiles, but untested And certainly won't work!
2023-02-17 08:57:25 -08:00
MsgAndTopicProc proc, void* closure,
API cleanup and all done This should complete sending to multiple topics (for backwards compatibility) and supporting combined messages in the future (sending them is hard; receiving not so much.)
2022-12-20 11:55:30 -08:00
const MQTTDevID* addressee,
compiles, but untested And certainly won't work!
2023-02-17 08:57:25 -08:00
XP_U32 gameID );
use persist flag and new per-game mqtt topics (too) I didn't understand MQTT at all. Per the docs anyway it only keeps a message around if its "persist" flag is set, and then it only keeps the most recent per topic. I expected that when a device connected, messages would be waiting for it, but that's apparently not true (some evidence to the contrary.) But having all games on a device share the same topic means only one message can be waiting. So switch to including gameID in the topic, subscribing to a wildcard topic and sending to a different one per game. For now, for legacy purposes, we'll keep sending to the old per-device topic.
2022-12-16 13:33:36 -08:00
void dvc_parseMQTTPacket( XW_DUtilCtxt* dutil, XWEnv xwe, const XP_UCHAR* topic,
const XP_U8* buf, XP_U16 len );
snapshot: registering from linux works
2024-02-13 14:38:52 -08:00
snapshot: async return of web api result works both platforms
2024-02-15 08:54:48 -08:00
void dvc_onWebSendResult( XW_DUtilCtxt* dutil, XWEnv xwe, XP_U32 resultKey,
XP_Bool succeeded, const XP_UCHAR* result );
snapshot: registering from linux works
2024-02-13 14:38:52 -08:00
/* All platforms need to call this shortly after setting up their XW_DUtilCtxt */
void dvc_init( XW_DUtilCtxt* dutil, XWEnv xwe );
snapshot: cleanup cleanup
2024-02-15 16:48:14 -08:00
void dvc_cleanup( XW_DUtilCtxt* dutil, XWEnv xwe );
snapshot: registering from linux works
2024-02-13 14:38:52 -08:00
add new files device{c,h} I've long wanted common code and state that outlast a single game. The smsproto stuff is a step in that direction, but this file will be a place for anything new. Starting, perhaps, with a mapping of deviceID -> addressInfo (e.g. BT name or SMS number of opponent device) that will let me stop duplicating that stuff in every game's comms state. We'll see. It's guarded by a compile-time flag so I can play with in on the Linux version until ready.
2020-01-08 10:19:01 -08:00
#endif
Reference in a new issue Copy permalink