Is it able to directly use socket() API in server while use thrift lib in client?
As directly use the API include socket(), write(), etc, there is no Protocol here, directly write a struct.
While in client, it use org.apache.thrift.protocol.TProtocol.readStructBegin, readString, readI64, etc...
Sure. The common part of any software/communication contract is that both sides must adhere to the protocols(s) as specified. But there is no law that you have to do it in one specific way only.
Related
Socket.io has provided docs about io.Manager class. It also tells about how to make a manager object. But it does not use this manager object anywhere in any example.
I want to ask whether this Manager class has any practical use or not. Since I am new to Socket.io, it would be helpful if someone tell the use of manager object with an example in layman way. If there is no direct use of manager object in making an application, then confirm it also.
See these docs: https://socket.io/docs/v4/client-api/#manager
The Manager manages the Engine.IO client instance, which is the low-level engine that establishes the connection to the server (by using transports like WebSocket or HTTP long-polling). The Manager handles the reconnection logic. A single Manager can be used by several Sockets.
Please note that, in most cases, you won't use the Manager directly but use the Socket instance instead.
I know, that some web-clients can't use PUT/PATCH/DELETE http methods.
I heard about clients, which uses Flash, and about simple http forms.
Have you had such problems? With which web-frameworks on client side?
Should I expect some problems with custom http headers, which some clients will not be able to send? (e.g. X-HTTP-METHOD-Override)
All these three methods are not commonly used and by default
GET
POST
QUERY
are three methods that are allowed so if you want to use
PUT
PATCH
DELETE
You will have to configure them in your webserver to allow these methods which depends on framework and server configuration in which your application is running
I am looking over csipsimple app - uses sip calls, registers. I also found samplecsipsimple that registers a sip client to the a sip server using the csipsimple as a library. I would like how to create an outbound call and imbound call on wifi using csipsimple as a library?
Need some help.
Appreciate
Since CSipSimple uses a wrapper for pjsua, you should take a look at simple-pjsua program. And since there is no callback mechanism in Java, you wont be able to use the callbacks (such as on_call_state). so what you need to do is to extend the Callback class and override all of it's methods. Look in the code how it is done.
We use XMPP XEP-0060 pub/sub feature to build a notification system.
According to XEP-0060, node can be created automatically when publishing.
My question is can it be created when subscribing?
If not, is there any alternative solution to implement this? (create node after subscribed)
Thanks
There's no inherent reason this can't be done transparently on the server-side. Prosody has a service-wide autocreate_on_subscribe option, for example.
Not via the XEP, as it doesn't specifically have that use case. You will have to either use a server that supports this natively, (as mentioned by #MattJ) or extend one to do so yourself, as most XMPP servers have some form of plugin/extension mechanism built in.
The caveat though, is that this is no longer to spec and you will be tied to a specific implementation so your application will not be portable.
We are building a proprietary system involving a client and a server linked over TCP/IP. Occasionally, the server will have some new expected or unexpected information that would be of interest to the client. My understanding is that SOAP and REST are query/response systems that require the client to request something and the server responds back. We need the client to register and the server to respond back if and when the new information is available. Are these protocols capable of such behavior? In addition, we need standard database-like queries requiring immediate response.
If you are in the Microsoft world, take a look at WCF, it is capable of this type of communication.
Whether you are in the Microsoft world or not, I would suggest looking into XMPP and AMQP.
First, REST isn't a protocol, it's more of an architecture style.
Second, neither of these are designed for push data delivery.
You could use either for the query-type messages, but you'll need to devise an out-of-band communication protocol to use for push notifications. If your data is fairly simple you could just use a basic TCP socket.