I am using a Prosys Opcua client as a test client for my server. According to the OPCUA specification, the client has to send a HEL packet to the server, then the server will acknowledge the client and the flow will continue up to a point where a connection is established.
I've noticed that the prosys client sends the HELLO message in chunks, its sends HE then L and continues to send bytes until the the HELLO packet is complete.
I find this behavior to be abnormal , and i can't seem anywhere in the specification where the spec says HELLO message can be transmitted in chunks.
When i use other clients , the HELLO message is sent as a single packet.
Below is a snapshot for wireshark showing packets sent by prosys client, i have highlighted the hello packet, the final hello only contains the endpoint url, all other attributes of the HELLO message are sent above the HELLO packet.
Is this standard behavior ? if yes which part of the specification mentions about this ?
As far as I can know, this is compliant, although sub-optimal. The OPC UA TCP mapping does not concern itself with how the messages are split into network packets. Why should it? That is a low-level detail. Other protocols that build upon TCP do not care either (e.g. HTTP).
No part of the UA spec needs to mention this as "allowed", because there is no reason why it shouldn't be allowed - it is simply a property of some underlying protocol, and OPC UA cannot mandate that underlying protocols should behave differently from their standards.
Note that you have written "...transmitted in chunks". Just to be clear, the "chunks" that you are observing are IP packets that carry TCP segments. They are not "message chunks" that OPC UA Part 6 (Mappings) describes - they cannot be, as they apply to UA secure conversation protocol, and the Hello message is sent before that protocol comes to use.
Related
Hi guys I'm new to understanding protocols used over the web and need some help in understanding the basics of websockets,TCP/IP and HTTP.
My understanding of the relation between TCP/IP and HTTP is that IP is required to connect all networks. TCP is a mechanism that allows us to transfer data safely and HTTP, which utilizes TCP to transfer its data, is a specific protocol used by Web servers and clients.
Does this mean you can't send a HTTP request without TCP?
Websockets communicate using TCP layer and a connection between client and server is established through HTTP which is known as the handshake process.
Does websockets have its own protocol? How can you send a http request(hand shake process) to establish TCP/IP when you need TCP to carry out an HTTP request. I know I am missing something really important here and would be great to get my understanding of these protocols sharpened!
Firstly, IP is not necessarily required to connect all networks. However, it is the most widely used and adopted today (For now that is). Old network protocols such as Appletalk, IPX, and DECNet are all legacy network protocols that are not much used anymore, however they are still around to an extent. Don't forget IPv6 is out there as well, in some places, and can ride over IPv4 networks if your configuration is done properly.
When you say TCP being "safe", I would give it another word, and that would be intelligent. TCP is a transport protocol, and is the header that comes directly after the IPv4 header. TCP is primarily used for flow control and has become very efficient at error recovery in case a part of a packet or packets has been last when transferring/receiving. While this is great for some transactions, the error control requires an additional amount of overhead in the packet. Some applications, let's say VoIP for example, is very sensitive to delay, jitter (Variation in delay) and congestion. This is why it uses UDP.
Like TCP, UDP is a transport protocol, however there is no flow control. Think of it this way: When sending packets over TCP, it's like asking the other end if they received your message. If they did, they will acknowledge it. If not, you now have to determine how you will resend this information. UDP has none of this. You send your message to the other side, and hope it gets there.
Now if you want to talk about "safe" protocols, this is usually done at either the network layer (IPSec) or the application layer (SSL). Safe typically means secured.
A usual TCP three-way handshake looks like this:
Whoever sends the SYN is the client. Whoever receives that initial SYN is the server.
Client sends SYN --> Server
Now, if the server is listening, and/or there's not a firewall blocking the service (Which in that case you'd receive a TCP frame from the server with the RST,ACK bits set most likely), the server will respond with a SYN-ACK:
Server sends SYN/ACK --> Client
If the client received this packet, he will acknowledge he received it. This completes the three-way handshake and these two may begin exchanging information.
Client sends ACK --> Server
Here's a good site for some info:
http://www.tcpipguide.com/free/index.htm
I'm writing a distributed chat application in Erlang for my own learning/benefit. I have a client and a server which maintain a persistent TCP connection. The client initiates the connection using gen_tcp:connect/3. The server is actually distributed over several nodes.
The gen_tcp documentation says:
Packets can be sent to the returned socket Socket using send/2. Packets sent from the peer are delivered as messages:
{tcp, Socket, Data}
Because of this, my client is able to receive any data the server sends as a normal Erlang message. This is desirable for my application.
The problem is that I can't see any way to make the connection on the server act the same way. I would love it if my server could receive sent data as an Erlang message. This way, the server can send data (i.e. when another person in the chat room sends a message) while waiting for the client to send a message.
Is there any way to implement this behavior?
EDIT: I'm aware of prim_inet:async_accept/2, but I'd prefer a documented approach if possible.
Look at inet:setopts with option {active, once|true}. Good article about
This is a rather general question about TCP sockets. I got a client/server application setup where messages are sent over the wire via TCP. The implementation is done via C++ POCO, however the question is not related to a certain technology.
A message can be a request (initiated by the client) or a response (initiated by the server).
A request has the structure:
Message Header
Request Header
Parameters
A response has the structure
Message Header
Response Header
Parameters
I know TCP guarantees that sent packages will be delivered in the order they have been sent. However, nothing can be assumed about the timespan a delivery might need.
On both sides I have a read/send timeout configured. Now I wonder how to have a clean set up on the transmitted data after a timeout. Don't know how to express this in the right terms, so let me describe an example:
Server S sends a response to the client (Message Header, Response Header, Parameters are put into the stream)
Client C receives the message header partially (e.g. the first 4 bytes of 12)
After these 4 bytes have been received, the reception timeout occurs
On client-side, an appropriate exception is thrown, the reception will be stopped.
The client considers the package as invalid.
Now the problem is, when the client tries to receive another package, he might receive the lasting part of the "old" response message header. From the point of view of the currently processed transaction (send request/get response), the client receives garbage.
So it seems that after a timeout has occured (no matter whether it has been on client or server-side), the communication should continue with a "clean setup", meaning that none of the communication partners will try to send some old package data and that no old package data is stored within the stream buffer of the respective socket.
So how are such situations commonly handled? Is there some kind of design pattern / idiomatic way to solve this?
How are such situations handled within other TCP-based protocols, e.g. HTTP?
In all the TCP samples around the net I've never seen an implementation that deals with those kind of problems...
Thank you in advance
when the client tries to receive another package, he might receive the lasting part of the "old" response message header
He will receive the rest of the failed message, if he receives anything at all. He can't receive anything else, and specifically data that was sent later can't be received before or instead of data that was sent earlier. It is a reliable byte-stream. You can code accordingly.
the communication should continue with a "clean setup", meaning that none of the communication partners will try to send some old package data
You can't control that. If a following message has been written to the TCP socket send buffer, which is all that send() actually does, it will be sent, and there is no way of preventing it short of resetting the connection.
So you either need to code your client to cope with the entire bytestream as it arrives or possibly close the connection on a timeout and start again.
This question already has answers here:
What is the fundamental difference between WebSockets and pure TCP?
(4 answers)
Closed 4 years ago.
Trying to understand as best as I can the differences between TCP socket and websocket, I've already found a lot of useful information within these questions:
fundamental difference between websockets and pure TCP
How to establish a TCP Socket connection from a web browser (client side)?
and so on...
In my investigations, I went through this sentence on wikipedia:
Websocket differs from TCP in that it enables a stream of messages instead of a stream of bytes
I'm not totally sure about what it means exactly. What are your interpretations?
When you send bytes from a buffer with a normal TCP socket, the send function returns the number of bytes of the buffer that were sent. If it is a non-blocking socket or a non-blocking send then the number of bytes sent may be less than the size of the buffer. If it is a blocking socket or blocking send, then the number returned will match the size of the buffer but the call may block. With WebSockets, the data that is passed to the send method is always either sent as a whole "message" or not at all. Also, browser WebSocket implementations do not block on the send call.
But there are more important differences on the receiving side of things. When the receiver does a recv (or read) on a TCP socket, there is no guarantee that the number of bytes returned corresponds to a single send (or write) on the sender side. It might be the same, it may be less (or zero) and it might even be more (in which case bytes from multiple send/writes are received). With WebSockets, the recipient of a message is event-driven (you generally register a message handler routine), and the data in the event is always the entire message that the other side sent.
Note that you can do message based communication using TCP sockets, but you need some extra layer/encapsulation that is adding framing/message boundary data to the messages so that the original messages can be re-assembled from the pieces. In fact, WebSockets is built on normal TCP sockets and uses frame headers that contains the size of each frame and indicate which frames are part of a message. The WebSocket API re-assembles the TCP chunks of data into frames which are assembled into messages before invoking the message event handler once per message.
WebSocket is basically an application protocol (with reference to the ISO/OSI network stack), message-oriented, which makes use of TCP as transport layer.
The idea behind the WebSocket protocol consists of reusing the established TCP connection between a Client and Server. After the HTTP handshake the Client and Server start speaking WebSocket protocol by exchanging WebSocket envelopes. HTTP handshaking is used to overcome any barrier (e.g. firewalls) between a Client and a Server offering some services (usually port 80 is accessible from anywhere, by anyone). Client and Server can switch over speaking HTTP in any moment, making use of the same TCP connection (which is never released).
Behind the scenes WebSocket rebuilds the TCP frames in consistent envelopes/messages. The full-duplex channel is used by the Server to push updates towards the Client in an asynchronous way: the channel is open and the Client can call any futures/callbacks/promises to manage any asynchronous WebSocket received message.
To put it simply, WebSocket is a high level protocol (like HTTP itself) built on TCP (reliable transport layer, on per frame basis) that makes possible to build effective real-time application with JS Clients (previously Comet and long-polling techniques were used to pull updates from the Server before WebSockets were implemented. See Stackoverflow post: Differences between websockets and long polling for turn based game server ).
UDP doesnot sends any ack back, but will it send any response?
I have set up client server UDP program. If I give client to send data to non existent server then will client receive any response?
My assumption is as;
Client -->Broadcast server address (ARP)
Server --> Reply to client with its mac address(ARP)
Client sends data to server (UDP)
In any case Client will only receive ARP response. If server exists or not it will not get any UDP response?
Client is using sendto function to send data. We can get error information after sendto call.
So my question is how this info is available when client doesn't get any response.
Error code can be get from WSAGetLastError.
I tried to send data to non existent host and sendto call succeeded . As per documentation it should fail with return value SOCKET_ERROR.
Any thoughts??
You can never receive an error, or notice for a UDP packet that did not reach destination.
The sendto call didn't fail. The datagram was sent to the destination.
The recipient of the datagram or some router on the way to it might return an error response (host unreachable, port unreachable, TTL exceeded). But the sendto call will be history by the time your system receives it. Some operating systems do provide a way to find out this occurred, often with a getsockopt call. But since you can't rely on getting an error reply anyway since it depends on network conditions you have no control over, it's generally best to ignore it.
Sensible protocols layered on top of UDP use replies. If you don't get a reply, then either the other end didn't get your datagram or the reply didn't make it back to you.
"UDP is a simpler message-based connectionless protocol. In connectionless protocols, there is no effort made to set up a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction, from source to destination without checking to see if the destination is still there, or if it is prepared to receive the information."
The machine to which you're sending packets may reply with an ICMP UDP port unreachable message.
The UDP protocol is implemented on top of IP. You send UDP packets to hosts identified by IP addresses, not MAC addresses.
And as pointed out, UDP itself will not send a reply, you will have to add code to do that yourself. Then you will have to add code to expect the reply, and take the proper action if the response is lost (typically resend on a timer, until you decide the other end is "dead"), and so on.
If you need reliable UDP as in ordering or verification such that TCP/IP will give you take a look at RUDP or Reliable UDP. Sometimes you do need verification but a mixture of UDP and TCP can be held up on the TCP reliability causing a bottleneck.
For most large scale MMO's for isntance UDP and Reliablity UDP are the means of communication and reliability. All RUDP does is add a smaller portion of TCP/IP to validate and order certain messages but not all.
A common game development networking library is Raknet which has this built in.
RUDP
http://www.javvin.com/protocolRUDP.html
An example of RUDP using Raknet and Python
http://pyraknet.slowchop.com/