I need to build a backend for an iPad app done in Objective C. I have two choices for that, one being Java and other C#.
With a backend built in either one of those, what options do I have to put the backend and frontend together? One option could be to use XML messaging. What are the other options?
Also what is the standard way of doing this? i.e. if we have an objective C frontend, then what should the backend be in and what communication mechanism should be used between the two?
I did some reasearch and am sure that either of Java or C# would work, but I could not find much information on how to make them work with the frontend? (Please bear in mind someone else would be doing the frontend)
Thanks.
You have a few things to consider. Wire protocol and Message protocol.
Wire Protocol:
This will contains things like the Message Id, Sender, Subject, Type, Timestamp, Message Size, etc. This is just as important as the Message Protocol. In order to recommend a Wire protocol I'd need to know more about your system. If you want a simple Wire protocol that will work on all those platforms you can take a look at STOMP. It is a simple ASCII based protocol for transmitting messages. It can be useful for debugging messages etc. ActiveMQ and RabbitMQ are Brokering systems that supports STOMP. I prefer RabbitMQ.
Simple STOMP message:
SEND
destination:/queue/a
content-type:text/plain
hello queue a
^#
You can also use HTTP as a simple wire protocol. It is simple and ASCII based like STOMP. Plus SOAP typically uses HTTP as it's transport protocol. SOAP also typically uses XML for it's message format to encode the Envelop, header and body of a message.
There is also JSON-RPC.
Message Format:
Most of the information in the Wire Protocol is used to determine where the message goes, if it got there, what type of information is in the message etc. Generally it is only used by the messaging system you put in place to send and receive messages. What your business logic is interested in, is the message content itself. You need a way to encode that content that both sides understand. There are plenty of choices for this: JSON, XML, Google's protobuf (binary).
I would have a hard time recommending any of these without more knowledge of what you need to do. They each have their own strengths and weaknesses.
Real-world mapping for wire and message protocols:
UPS, US Postal, FedEx = wire protocol
letter from mom, loan application, birthday card = message
Related
I have a simple Web API that receives POST messages from geographically dispersed clients.
I have a swathe of WinForms Applications that act as "satellite" applications which send payloads to websites. So these applications maintain state, logins, and other functionality specific to each website they represent.
Theory is:
WebAPI receives a request, and sends it to the specific WinForms application which then forwards on the payloads as per its requirement.
So External Client->Web Api Post->?IPC MECHANISM HERE? Sends Payload->WinForms Delivers Payload->Sends Response back->Back up the pipe and back through WebAPI
Where I am "missing" at the moment is the most efficient and quickest way possible for my my POST Request, to get the message to the respective WinForms Application AND get a response.
I have been reading about signalR. I have been able to create a Hub and send a message to one client (which is all I have for testing now anyway). BUT - I have read this morning that I cannot get "return" messages back from my client.
Some of the SO messages about this are dated and brings me to my question - is there any way I can achieve this with SignalR.
As an appendix to the question:
If not, are there alternative bits of tech I can be advised to review or pursue as an alternate?
FYI - I did have this all wired in internally to WebAPI itself which then simply responded with the return values, but as requirements have grown - "state"/"logins"/"sessions"/"cookies" need to be maintained which prompted the decision to "externalise" each payload delivery system.
I need to write a server that will handle a binary protocol with TLS. Nothing to do with HTTP or SOAP. But it needs to be able to accept incoming connections, with client certificates, maybe pooling, and provide responses. Ideally could also post messages back to the client asynchronously but not a requirement.
Can this be done with a special IIS plug in? or with WCF? Or is it best done by just listening on a raw socket?
Edit. To be clear, this is a binary protocol that is well defined by an industry standard. I do not want any software to interpret it, package things into objects etc. I just want to have a listener send bytes sent by a client to a class and then send them back.
I think Remoting can help you, you can make your own channel for example
The project is to build a messaging mechanism between a Python and C# program via ZeroMQ .
I want messages to be able to travel in/out from both ends at any time, which is NOT a basic request-reply model a.k.a. REQ/REP.
One way I can think of is to build a PUB/SUB model on two ports, i.e. two one way channels.
Is there any method to get a real duplex channel?
There are several ways to do this with ZeroMQ. I suggest using a DEALER/ROUTER socket pair:
Choose one program to be the "server", the other the "client".
The server will bind a ROUTER socket on a port.
The client will connect a DEALER socket to the server's ROUTER port.
(Note: this implies that the client must know the server's IP and port in advance.)
At this point the client can send messages to the server, but the server has no way to send to the client.
The client sends a "HELLO" message to the server.
The server will receive a message that includes the client's address and the HELLO message. Now the server can send messages to the client using the client's address.
DEALER/ROUTER is considered an "advanced" socket pair in ZeroMQ. My description here is very high level. You'll really need to read the docs to get the most out of ZeroMQ.
Oh yes, Sir!
Use the PAIR-PAIR or even the XREQ-XREP ought make it.
The best next step is to carefully read the respective Scalable Formal Communication Pattern archetypes' access-points' API documentation, so as to cross-check, that all pieces of pre-wired behavioural logic meet your Project needs and voilá, harness them in your messaging setup and tune-up the settings so as to meet you performance and latency needs.
That is this simple ( thanks to all the genuine knowhow hidden in these builtins ).
Using for years this very sort of inter-platforms integration among Python + C/MQL4 and other computing nodes, so well worth one's time to learn the powers and strengths of ZeroMQ.
After sending some tcp data with the blocking/non-blocking methods such as:
Socket.Send() or Socket.SendAsync()
How can I know that my data has received an ACK message?
Can .NET know if TCP data has been successfully sent?
The only way to know for sure is to implement some kind of application-level acknowledgement. The TCP level "ACK" packet is not exposed to the application level at all, so you have to use something more than that.
You make the other end respond to it.
Even if TCP has Acked it, if the receiving end terminates (for good or bad reasons) before processing the message and acting on it, you still don't know, so the only way to know is for the other end to tell you.
This information isn't available from .net's class libraries. I had the same kind of considerations when I started working on this port scanner in C#. I have made use of a .NET wrapper for libpcap (after installing the corresponding driver), the SharpPcap (http://sourceforge.net/projects/sharppcap/), in order to get this kind of information. The ACK packets are obtained through SharpPcap's interface (invoking the native libpcap interface's transparently).
My application is NScanner Port Scanner/Sweeper and you can find the code at codeplex, referencing to you my simple usage of the aforementioned library (http://nscanner.codeplex.com/).
I hope I helped.
"I'm trying to focus on how can you know when your data has been accepted by the other-side of the connection."
I think you need to be aware what type of application layer protocol you are going to implement and what impact this has on application performance.
Take HTTP as an example of a "Streaming like" protocol. A server posts a stream of data to a client. There are no more additional application layer "ACKs" and the server doesn't actually care when and how exactly his stream of data arrives. This is very efficent on high latency links.
Now compare this to SMB! Instead of streaming a file, data is partitioned into blocks. Every successfully transferred block of data is acked on the application layer. This gives you more control, however, it effectively kills the protocol on WAN networks (check out "Bandwidth Delay Product").
Taking this into consideration, you can come up with your own design for your custom protocol.
The TCP layer will keep resending the packet until it receives a successful ACK.
Send will block until this happens - SendAsync will not block, and you can continue processing other stuff while the TCP layer handles sending the packet.
I recommend using Pcap.Net.
You can easily sniff packets using this library in C# and then easily check the packet values.
You can also easily build and send packets.
If you are really certain that you need to know the packet level details of your TCP connection, then in addition to creating the TCP socket for sending, you need your application to use the winpcap API to look at the raw traffic as well. You can install a filter to only receive packets relevant to the particular IP,port combination that determines your remote side.
There are a couple of projects out there creating .NET wrappers for libpcap, for example here
Lets say I have my C# app installed on 2 laptops connected to a WiFi Wireless Local Area Network.
How can these apps send messages to each other? What method or library can I use? I heard of using sockets but I have no idea how to work with these.
You could use WCF to build a communication pipe between the 2 applications. WCF encapsulates the sockets into a more manageable interface. You can start here.
Basically, you'll want to do it the same way you would in any other language. You'll open a network connection of one flavor or another (raw TCP or UDP, or a higher level protocol like HTTP) with one side acting as a server and the other acting as a client. Then each side can write data through or read data sent by the other side. It's can get pretty complicated from there. If you Google "C# Sockets" or "C# HTTP", etc, you'll find quite a few tutorials on the subject.
This is a very good article on sending C# objects (which could include whatever messages that you want to send) over a Socket connection using the Binary Formatter. Although it is not the most efficient, it is quite easy to grasp and get working.