jeremyczhen / fdbus Goto Github PK

View Code? Open in Web Editor NEW

160.0 18.0 85.0 3.69 MB

FDBus - Fast Distributed Bus

Home Page: https://blog.csdn.net/jeremy_cz/article/details/89060291

CMake 1.54% C++ 76.09% C 10.64% Java 7.40% Makefile 0.13% Python 4.21%

ipc platform soa

fdbus's Introduction

由于github网速太慢，FDBus迁移到gitee上，github已经不再维护。请访问 https://gitee.com/jeremyczhen/fdbus 获得FDBus最新版本，谢谢！

fdbus's People

Contributors

Stargazers

Watchers

Forkers

ben-ying mao3511 xtang2010 mmalb xiaos09lzu skawu givemelose sanwenkit hwei0885 zengsamuel lubin20999 leon1205 guq00226 lanbengbeng lewis081 w545029118 qingfengforum-fork danielcxh hanagm sunclgogo ce123 ganggangliu lichenxuan87 bytexiaotang developjoy runmousefly zbjlu boyalucky shanghaixusheng zyqiang0713 voicialex yidezhangfei cshr syfchao jfq3301 hjshtr stoneboy100200 dingjiangang blueff paultcn finalx shh632058099 huangqinggan johnsmithsss uniuz yang0000qi forlearngit julianayuan yaozhi1234 snail1998 anccny caiminjie githubzhy lifangwang xiaowulovenana louislau86 xiaojiefan jinjiangd zengcaixu mingpuwu link-1112 qsbird askzhao jjzhang166 icallservice heguolun qiancheng0114 shuhecn wenfei-alibaba yongyuwh longgoal oaman gt-liu2016 xfunk ivan-kits dreamjdm juewuzixing 783491064 wlc123456 sylvierick jackylucifer

fdbus's Issues

大量数据通信时、fdbus会出现卡滞

通过logsvc工具查看、logsvc输出的log会出现卡滞现象、在具体场景中的表现是：fdbus client上在几秒钟内会出现无法通信的情况、其他server向client broadcast的数据、要几秒钟后才能收到。
branch：hotfix_autoreply_for_sunclgogo。
@jeremyczhen 希望有时间帮忙看下、谢谢！

CBaseSemaphore 系统时间变化，卡掉的问题

BaseWorker 默认创建 CThreadEventLoop ；

Linux 平台，其 dispatch函数中会用到信号量操作，其中信号量的超时时间用到了：

clock_gettime(CLOCK_REALTIME) + sem_timedwait

再运行过程中，如果系统时间有变化，会不会导致卡死卡死状态？

Fdubs跨域是点对点服务通信，中间的nameserver只做了服务发现。缺陷在于服务太多时，通信效率会降低，尤其是在服务提供者提供服务，订阅者偏多时。这就是服务网关存在的意义。
对比vsomeip,跨域通信都经过stub中转，订阅单位基于ip, 订阅量会大幅降低，配合field机制，通信量会少许多。虽然链路好像会长一点。
但经过比对测试，在5ms通信以下级别，fdbus通信负载比vsomeip负载大的多。

fdbus invoke 接口交叉编译在QNX系统上，for循环调用不成功

前提：fdbus库交叉编译在QNX系统上运行
动作：执行fdbus库自带的性能测试代码：fdbxserver 与 fdbxclient, 不加任何参数
附加动作：在源码中的onInvoke和onReply接口的开始加上了printf打印，用来表明进入该函数
运行结果：只打印了6次onInvoke，1次onReply
其它：在自己编写的测试代码中，for循环异步调用invoke接口，10次可以执行，1000次就不可以了，现象同上

protocol buffer交叉编译报错

cmake -DCMAKE_INSTALL_PREFIX=install -DBUILD_SHARED_LIBS=1 -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake ../cmake
toolchain.cmake内容：
“SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_C_COMPILER /home/marina/qnx700_ES9/host/linux/x86_64/usr/bin/ntox86_64-gcc)
SET(CMAKE_CXX_COMPILER /home/marina/qnx700_ES9/host/linux/x86_64/usr/bin/ntox86_64-g++)”
make后报错内容如下附件：

请问一下是哪里配置错误了

fdubs timer may has problem

the CBaseLoopTimer may has problem.
程序有需求，消息来时创建timer指针，得到回复之后就delete指针。
这样来回new和delete大概几百次之后，就会引起程序cordump.

QNX下编译找不到TCP_KEEPIDLE TCP_KEEPINTVL TCP_KEEPCNT

if (setsockopt(CastToSocket(socket), IPPROTO_TCP, TCP_KEEPIDLE, &val, sizeof(val)) < 0) {
    return false;
}

/* Send next probes after the specified interval. Note that we set the
 * delay as interval / 3, as we send three probes before detecting
 * an error (see the next setsockopt call). */
val = interval / count;
if (val == 0) val = 1;
if (setsockopt(CastToSocket(socket), IPPROTO_TCP, TCP_KEEPINTVL, &val, sizeof(val)) < 0) {
    return false;
}

/* Consider the socket in error state after three we send three ACK
 * probes without getting a reply. */
val = count;
if (setsockopt(CastToSocket(socket), IPPROTO_TCP, TCP_KEEPCNT, &val, sizeof(val)) < 0) {
    return false;
}

interface onReply may receive some data we not use

core dump(CBaseEndpoint::deleteSocket)

I made preliminary analysis for the source code of CBaseEndpoint class. found a problem, i am not sure. maybe it is my false understanding.
I find there is only call "insertEntry" in "CBaseEndpoint::addSocket" , but no call "deleteEntry" in "CBaseEndpoint::deleteSocket".
which may cause the "container" never empty. and the following source code could be called for many times:
void CBaseEndpoint::deleteSocket(FdbSocketId_t skid)
{
...
while (!containers.empty())
{
EntryContainer_t::iterator it = containers.begin();
delete it->second; // also deleted from socket container
}
...
}

Finally, when execute the " delete it->second;" for the second time, the core dump will happen. right?

QNX交叉编译错误

如下：
cmake -DCMAKE_INSTALL_PREFIX=install -DSYSTEM_ROOT=~/workspace/protobuf-test/aarch64_out/ -DCMAKE_TOOLCHAIN_FILE=../../toolchain.cmake -Dfdbus_SOCKET_ENABLE_PEERCRED=OFF -Dfdbus_PIPE_AS_EVENTFD=true ../cmake/
make

Some problems with the use of fdbus

hi,jeremy!
1、I want to use fdbus as the BUS of RTE, is it appropriate? Do you have any suggestions?

2、Which fdbus version do you recommend is more appropriate?

thank you!

compile fdbus with android ndk

Have you compiled fdbus with android ndk and run the servers on Android?

高频率调用invoke时会产生oom

hi jeremy @jeremyczhen
在高频调用invoke时、FDB_CONTEXT线程会发生oom、请问这个问题跟最近修改的内存泄漏问题有关么？invoke使用的原型参照下面：
nvoke(FdbMsgCode_t code
, const CFdbBasePayload &data
, int32_t timeout)

condition_variable_any use system time, which will affect by system time change

use condition_variable which use steady time also may affect by system time change

ndk编译出现clang++: error: linker command failed with exit code 1

ubuntu系统，ndk20b命令如下：
cd ~/workspace
git clone https://github.com/protocolbuffers/protobuf.git protobuf-host
cd protobuf-host && git submodule update --init --recursive && cd ..
cp protobuf-host protobuf-target -r

cd ./protobuf-target;mkdir -p build/install;cd build

cmake -DCMAKE_INSTALL_PREFIX=install -DBUILD_SHARED_LIBS=1 -DANDROID_LINKER_FLAGS="-landroid -llog" -Dprotobuf_BUILD_PROTOC_BINARIES=0 -Dprotobuf_BUILD_TESTS=0 -DCMAKE_TOOLCHAIN_FILE=~/android-ndk-r20b/build/cmake/android.toolchain.cmake ../cmake

PATH=~/workspace/protobuf-target/build/install/bin:$PATH make -j4 install
报错如下
[ 52%] Linking CXX shared library libcommon_base.so
/home/asd/workspace/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld: error: cannot find -lpthread
/home/asd/fdbus/fdbus/CBaseClient.cpp:96: error: undefined reference to '__android_log_print'
/home/asd/fdbus/fdbus/CBaseClient.cpp:100: error: undefined reference to '__android_log_print'
/home/asd/fdbus/fdbus/CBaseClient.cpp:105: error: undefined reference to '__android_log_print'
/home/asd/fdbus/fdbus/CBaseClient.cpp:182: error: undefined reference to '__android_log_print'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
CMakeFiles/common_base.dir/build.make:1056: recipe for target 'libcommon_base.so' failed
make[2]: *** [libcommon_base.so] Error 1
CMakeFiles/Makefile2:321: recipe for target 'CMakeFiles/common_base.dir/all' failed

python接口client端invoke_sync调用service服务已经回复client，但client解析回复为空

service端：
def on_invoke(self, sid, msg_code, msg_data, reply_handle):
if msg_code == baseCanservice.GWM_GET_T_Box_FD1:
message_status = baseCanservice.BroadcastMessageStatus()
message_status.ParseFromString(msg_data)
print('onInvoke: msg status is: ', message_status.msg_status)
now_playing = baseCanservice.SetSignalValueRequest()
now_playing.raw_value = b'a'
now_playing.type = 1
reply_data = now_playing.SerializeToString()
# reply_data = message_status.SerializeToString()
print("replay client serialize data is:{}".format(reply_data))
reply_handle.reply(reply_data)
reply_handle.destroy()

client端：
msg = client_list[i].invoke_sync(baseCanservice.GWM_GET_T_Box_FD1, send_data)

service端日志：
MyTestServer: onOnline
on_online for server service3 , first: True
onInvoke: msg status is: 2
replay client serialize data is:b'\n\x01a\x10\x01'

client端日志：
send message data is:b'\x08\x02'
On online for client service3
accept server reply data is:{'sid': 0, 'msg_code': 0, 'msg_data': None, 'status': -128, 'msg_buffer': None}
Error for sync invoke: -128
double free or corruption (out)
Aborted (core dumped)

期待回复！！！！

void onInvoke(CBaseJob::Ptr &msg_ref) 中的msg_ref有问题

msg_ref为智能指针，但是被捕获切换线程处理，好像已经被删除，为空。
后来只能如下处理，将其中的值先取出，赋给buffer
CBaseMessage *msg = castToMessage<CBaseMessage *>(msg_ref);
if (nullptr != msg)
{
std::shared_ptrstd::string buffer(std::make_sharedstd::string());
buffer->assign((char *)(msg->getPayloadBuffer()), msg->getPayloadSize());
int32_t code = msg->code();
}
});

CBaseSemaphore have problem, suggest not use

sem_timedwait use CLOCK_REALTIME time, which may change when system time change. so timewait will have problem.

[Non-Issue] FDBus performance & features discussion

Okay, first I need declaim that the following content might not an issue, but a few interesting questions in my mind, which might be same ones as most of us in this field might interested in. Thanks for your contribution of IPC implementation in open source world, it is great job, and we could learn a lot from your achievements. Meanwhile, we would thank you for sharing your project in Github.

The FDBus were implemented based on Client-Server messaging model as you recorded in your blog, we are interested in the background or trade-off when you make decision on choosing Client-Server Model. As we know in In-Vehicle industry, there is trends in which consists of time-critical information delivery, large quantities of information exchange, unreliable delivery mechanism, all these scenario could happen in the near future Autonomous Car industry. Therefore, I will appreciated if you could share more information regardless evaluation details/results of FDBus solution with real-time delivery performance, resources overhead, etc. (I know this might not be good way to ask for directly, especially in open source world). You can just ignore it

Anyway, thanks for your contribution! We learn a lot from it.

How to use "void CFdbBaseObject::getSubscribeTable(...)" API conveniently without limitation "must be used within context"

I found the API "void CFdbBaseObject::getSubscribeTable(...)" cannot be called in worker(self-thread). because:
1.the API"void CFdbBaseObject::subscribe(CFdbSession *session, FdbMsgCode_t msg, FdbObjectId_t obj_id, const char *filter)" is only called in CONTEXT thread.
2.both getSubscribeTable and subscribe have no lock/unlock mechanism.

But, usually, the user like to create a CBaseClient or CBaseServer with a separate worker attached, which will easily cause the "getSubscribeTable" API called in worker thread. not very friendly.

So，in order to use getSubscribeTable without any limitation. i have an immature idea to add lock mechanism in below interfaces:
1.CFdbBaseObject::subscribe(CFdbSession *session, FdbMsgCode_t msg, FdbObjectId_t obj_id, const char *filter)
2.void CFdbBaseObject::unsubscribe(CFdbSession *session, FdbMsgCode_t msg, FdbObjectId_t obj_id, const char *filter)
3.void CFdbBaseObject::unsubscribe(CFdbSession *session)
4.void CFdbBaseObject::unsubscribe(FdbObjectId_t obj_id)
5.void CFdbBaseObject::broadcast(CFdbMessage *msg)
6.bool CFdbBaseObject::broadcast(CFdbMessage *msg, CFdbSession *session)
7.void CFdbBaseObject::getSubscribeTabl(...)

But, i am afraid it will take side effect for the whole design and sequence.
Wish your appropriate advices!!!

invoke()耗时问题

您好，测试了fdbclienttest和fdbservertest，自定义message，统计invoke时间，统计方式如下：
clock_t start, finish;
double duration = 0;
start = clock();
invoke(ref, builder); /* onInvoke() will be called at server */
finish = clock();
duration = (double)(finish - start) / CLOCKS_PER_SEC;
，测试了三个message，有5%左右的概率会出现某个（三个随机出现）message对应的传输时间为2.5秒左右，其余基本小于2ms。
请问什么原因？

deadlock occur when BaseContext register in QNX OS

Hi, Jeremy,

发现一个初始化阶段的死锁现象，该问题发生在 BaseContext注册时，详细调用栈：
(CFdbBaseContext::tearup) ---> (FDB_CONTEXT->registerContext) ---> (sendSyncEndeavor) ---> sendSync。
发生该问题的根本原因是在QNX系统上线程创建pthread_create并不能保证线程执行体迟于pthread_create的返回；一旦线程执行体早于pthread_create的返回，BaseThread成员mThread并未赋值时sendSyncEndeavor中的isSelf返回false，最终导致Context线程内执行了sendSync，死锁发生。
使用sendAsyncEndeavor完成registerContext可以避免这个问题，但fdbus中仍有其他类似风险存在，因此需要一种线程执行体与pthread_create之间的同步机制；

Thanks

host server doesn't listen to 60000 port when run

when I first run host server, it doesn't listen to 60000 port.
After I run name server, it starts to listen.
My question is how can I connect my name server from remote if host server doesn't listen?

Audio长时间通信、传输数据时，ConnectorClient:CBaseClient会异常onOffline并很快重新onOnline

在两个系统host1、host2上分别建立了用于Audio连接的server/client。
host1：用于连接的ConnectorServer：CBaseServer；
用于数据传输的AudioClient：CFdbBaseObject；（通过Invoke( )函数发送数据）
Host Server

host2：用于连接的ConnectorClient：CBaseClient；
用于数据传输的AudioClient：CFdbBaseObject；（通过onInvoke( )函数接收数据）

在长时间使用上述通道进行Audio数据传输时，
偶现host2上ConnectorClient::onOffline( )，然后很快又ConnectorClient::onOnline( )，

在出现问题时，host2上的其他fdbus module并没有onOffline、onOnline，只有Audio出现了此问题。

所以请问，出现这个问题可能的原因是什么？
有没有可能是host1发送的Audio数据过大，拥堵住了fdbus buffer？
又或者是host2上onInvoke( )函数内发生了block行为，上一次的onInvoke( )一直未正常return？

windows 下编译问题

请问封装了线程, 但是好像之后就没有使用封装的线程了, 在 CFdbSession.h 下直接调用了<pthread.h> 头文件, MSVC下不存在该头文件, 导致编译失败. 请问作者在window下成功编译过了吗?

JNI DETECTED ERROR IN APPLICATION: use of invalid jobject 0x8ce42550'

JNI跑起来的时候。
client Subscribe时，
Server会响应到CJniServer::onSubscribe(CBaseJob::Ptr &msg_ref)。
env->CallVoidMethod(mJavaServer,
CFdbusServerParam::mOnSubscribe,
msg->session(),
msg_handle,
obj_arr_list
);

-27 21:28:53.787 9079 9079 F DEBUG 03-27 21:28:53.787 9079 9079 F DEBUG 03-27 21:28:53.787 9079 9079 F DEBUG 03-27 21:28:53.787 9079 9079 F DEBUG 03-27 21:28:53.787 9079 9079 F DEBUG 03-27 21:28:53.787 9079 9079 F DEBUG : 03-27 21:28:53.787 9079 9079 F DEBUG : 03-27 21:28:53.787 9079 9079 F DEBUG : 03-27 21:28:53.787 9079 9079 F DEBUG : 03-27 21:28:53.799 9079 9079 F DEBUG 03-27 21:28:53.799 9079 9079 F DEBUG 03-27 21:28:53.799 9079 9079 F DEBUG : 03-27 21:28:53.799 9079 9079 F DEBUG : 03-27 21:28:53.799 9079 9079 F DEBUG : 03-27 21:28:53.799 9079 9079 F DEBUG : 03-27 21:28:53.799 9079 9079 F DEBUG : 03-27 21:28:53.799 9079 9079 F DEBUG : 03-27 21:28:53.799 9079 9079 F DEBUG : 03-27 21:28:53.799 9079 9079 F DEBUG : 03-27 21:28:53.799 9079 9079 F DEBUG : 03-27 21:28:53.799 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.800 9079 9079 F DEBUG : 03-27 21:28:53.871 1832 1832 E 03-27 21:28:53.871 1832 1832 E 目前来起来类型传的也没问题，大神能帮忙指导一下吗？ : Revision: '0'
: ABI: 'arm'
: pid: 8992, tid: 9066, name: Thread-4 >>> com.fdbus.server <<<
: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
: Abort message: 'java_vm_ext.cc:542] JNI DETECTED ERROR IN APPLICATION: use of invalid jobject 0x8ce42550'
r0 00000000 r1 0000236a r2 00000006 r3 00000008
r4 00002320 r5 0000236a r6 8ce42024 r7 0000010c
r8 00000000 r9 a841c740 r10 0000000a r11 a831f63e
ip 8ce41fc0 sp 8ce42010 lr aa234e69 pc aa22ccb6
:
: backtrace:
#00 pc 0001ccb6 /system/lib/libc.so (abort+58)
#1 pc 0034db4f /system/lib/libart.so (art::Runtime::Abort(char const*)+910)
#2 pc 000071b3 /system/lib/libbase.so (android::base::LogMessage::~LogMessage()+494)
#3 pc 0023203f /system/lib/libart.so (art::JavaVMExt::JniAbort(char const*, char const*)+1214)
#4 pc 0023220b /system/lib/libart.so (art::JavaVMExt::JniAbortF(char const*, char const*, ...)+66)
#5 pc 003733d9 /system/lib/libart.so (art::Thread::DecodeJObject(_jobject*) const+568)
#6 pc 000c363d /system/lib/libart.so (art::(anonymous namespace)::ScopedCheck::CheckInstance(art::ScopedObjectAccess&, art::(anonymous namespace)::ScopedCheck::InstanceKind, _jobject*, bool)+72)
#7 pc 000c29a7 /system/lib/libart.so (art::(anonymous namespace)::ScopedCheck::CheckPossibleHeapValue(art::ScopedObjectAccess&, char, art::(anonymous namespace)::JniValueType)+442)
#8 pc 000c2b1b /system/lib/libart.so (art::(anonymous namespace)::ScopedCheck::CheckPossibleHeapValue(art::ScopedObjectAccess&, char, art::(anonymous namespace)::JniValueType)+814)
#9 pc 000c20f5 /system/lib/libart.so (art::(anonymous namespace)::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::(anonymous namespace)::JniValueType*)+624)
#10 pc 000c6a2f /system/lib/libart.so (art::(anonymous namespace)::CheckJNI::CheckCallArgs(art::ScopedObjectAccess&, art::(anonymous namespace)::ScopedCheck&, _JNIEnv*, _jobject*, _jclass*, _jmethodID*, art::InvokeType, art::(anonymous namespace)::VarArgs const*)+94)
#11 pc 000c5c5f /system/lib/libart.so (art::(anonymous namespace)::CheckJNI::CallMethodV(char const*, _JNIEnv*, _jobject*, _jclass*, _jmethodID*, std::__va_list, art::Primitive::Type, art::InvokeType)+506)
#12 pc 000b767d /system/lib/libart.so (art::(anonymous namespace)::CheckJNI::CallVoidMethodV(_JNIEnv*, _jobject*, _jmethodID*, std::__va_list)+44)
#13 pc 000cc351 /data/app/com.fdbus.server-Py4O7px5unZO89fQrFOHdg==/lib/arm/libfdbus-jni.so (_JNIEnv::CallVoidMethod(_jobject*, _jmethodID*, ...)+76)
#14 pc 000cdd61 /data/app/com.fdbus.server-Py4O7px5unZO89fQrFOHdg==/lib/arm/libfdbus-jni.so (CJniServer::onSubscribe(std::__ndk1::shared_ptr&)+712)
#15 pc 00099831 /data/app/com.fdbus.server-Py4O7px5unZO89fQrFOHdg==/lib/arm/libfdbus-jni.so (CFdbBaseObject::doSubscribe(std::__ndk1::shared_ptr&)+36)
#16 pc 000abc71 /data/app/com.fdbus.server-Py4O7px5unZO89fQrFOHdg==/lib/arm/libfdbus-jni.so (CFdbSession::doSubscribeReq(NFdbBase::CFdbMessageHeader&, CFdbMessage::CFdbMsgPrefix&, unsigned char*, bool)+820)
#17 pc 000ab345 /data/app/com.fdbus.server-Py4O7px5unZO89fQrFOHdg==/lib/arm/libfdbus-jni.so (CFdbSession::onInput(bool&)+480)
#18 pc 000c14f1 /data/app/com.fdbus.server-Py4O7px5unZO89fQrFOHdg==/lib/arm/libfdbus-jni.so (CFdEventLoop::processWatches()+528)
#19 pc 000c19c9 /data/app/com.fdbus.server-Py4O7px5unZO89fQrFOHdg==/lib/arm/libfdbus-jni.so (CFdEventLoop::dispatch()+144)
#20 pc 000be4cd /data/app/com.fdbus.server-Py4O7px5unZO89fQrFOHdg==/lib/arm/libfdbus-jni.so (CBaseWorker::run()+116)
#21 pc 000b139f /data/app/com.fdbus.server-Py4O7px5unZO89fQrFOHdg==/lib/arm/libfdbus-jni.so (CBaseThread::threadFunc(void*)+18)
#22 pc 00063315 /system/lib/libc.so (__pthread_start(void*)+22)
#23 pc 0001de79 /system/lib/libc.so (__start_thread+24)
CarPowerManagerNative: Received unknown bootReason = 0
PowerTestService: ERROR: Could not read bootReason!!

visual-studio2019安装后，在windows上编译一直提示错误

C:\workspace\protobuf\cbuild>cmake -DCMAKE_INSTALL_PREFIX=install -Dprotobuf_WITH_ZLIB=OFF ..\cmake
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.18363.
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:20 (project):
No CMAKE_C_COMPILER could be found.

安装流程来的，windows平台编译一直卡在这里；linux上面可以编译成功。

【branch: v4.2.0】S级bug，S级bug,提供的python接口，get_sync方法，找不到c++提供的fdb_client_get_event_sync方法

操作步骤：
1.拉取v4.2.0,编译好后，加载window的fdb_lib.dll
2.起一个client的Publish方法
3.client调用异步的get_async方法是OK的
4.client调用同步的get_sync方法，直接报AttributeError: function 'fdb_client_get_event_sync' not found

主要client的publish代码：
if name == 'main':
client = server1()
# client.ex_client()
while True:
et = client.Example.ElapseTime()
et.hour = 13
et.minute = 59
et.second = 5
client.publish(client.Example.NTF_ELAPSE_TIME, 'python topic 1', et.SerializeToString())
time.sleep(1)

主要client的get_sync和get_async代码：
if name == 'main':
client = server1()
# client.ex_client()
while True:
client.get_async(client.Example.NTF_ELAPSE_TIME, 'python topic 1')
time.sleep(5)
msg = client.get_sync(client.Example.NTF_ELAPSE_TIME, 'python topic 1')
print(msg)
time.sleep(1)

####################### client的get_sync和get_async的报错信息如下 ################################
D:\works\ENVS\NOBO-ENV\Scripts\python.exe D:/works/NoboProject/NoBoCIA/common/fdbus/fdbus_template/fdbus_client_template1.py
2021-05-14 15:46:53.683 | INFO | NoBoCIA.common.fdbus.lib.BaseFdbus:start_name_server:97 - Connect qnx host server successful!
2021-05-14 15:46:58.726 | INFO | NoBoCIA.common.fdbus.lib.BaseFdbus:start_name_server:106 - Start name server successful!
2021-05-14 15:46:58.744 | INFO | main:on_online:52 - onOnline for client server1
2021-05-14 15:46:58.745 | INFO | NoBoCIA.common.fdbus.lib.BaseFdbus:on_online:516 - onOnline for client server1
2021-05-14 15:46:59.740 | INFO | NoBoCIA.common.fdbus.lib.BaseFdbus:on_get_event:547 - onGetEvent for client server1, code:3,topic:b'python topic 1',size:92
Traceback (most recent call last):
File "D:\works\NoboProject\NoBoCIA\common\fdbus\fdbus_template\fdbus_client_template1.py", line 103, in
msg = client.get_sync(client.Example.NTF_ELAPSE_TIME, 'python topic 1')
File "D:\works\NoboProject\NoBoCIA\common\fdbus\lib\BaseFdbus.py", line 447, in get_sync
self.fdb_clib.fdb_client_get_event_sync.argtypes = [ctypes.c_void_p,
File "d:\app\python\lib\ctypes_init_.py", line 387, in getattr
func = self.getitem(name)
File "d:\app\python\lib\ctypes_init_.py", line 392, in getitem
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'fdb_client_get_event_sync' not found

CONFIG_SOCKET_CONNECT_TIMEOUT does not work as expected.

We are using fdbus under QNX, and noticed that CONFIG_SOCKET_CONNECT_TIMEOUT does not work as expected.
CONFIG_SOCKET_CONNECT_TIMEOUT's default value is 2000 (ms), but connect() takes as long as 90s to time out.

It seems better to use select(), I will try select() later to see if it works.

fdbusmessage crush问题

fdbus在qnx端与Windows端进行通信的问题

作者你好，我这边在进行qnx端与Windows端连接时，Windows端不论是作为host_service还是name_service，都会在连接后又快速的RST连接，不知Windows端与qnx端通信是需要另外配置什么吗？请指教，谢谢！

protobuf3 适配问题

你好，fdbus如果使用protobuf3，当一端发送内容全为0的数据的时候，protobuf会认为这些值都是默认值从而序列化出来的数据为空，fdbus会将这个发出去，而在接收端调用msg->deserialize()函数的时候，因为
bool CFdbMessage::deserialize(IFdbMsgParser &payload) const
{
if (!mBuffer || !mPayloadSize)
{
return false;
}
return payload.parse(mBuffer + mOffset + mPrefixSize + mHeadSize, mPayloadSize);
}
这个函数里面有对长度的判断，从而直接返回false，这个问题应该怎么处理？