Apologies if my terminology is not correct with this question, but bear with me.
I know what I want to achieve, just not sure what the proper names are for the classes/functions etc.
I need to make a client/server application using tcplistener and tcpclient which will allow me to send both strings and files... I think.
So in layman's terms, I want to make a server application that will listen for connections from a client on a specific port. The clients will essentially connect to the server and say "hey, I'm client 172.16.10.12. I'm going to send you a file called test.txt, which is 2330k in size. The file's MD5 hash is xxxxxxxxxxx".
Once that communication has taken place, I want the client to then send the file 'test.txt' to the server; the server saving the file to an appropriate location before then generating the file's MD5 hash and comparing it to the MD5 and file size the client proposed, before finally reporting back to the client 'Ok' or 'Success'.
If the file size or MD5 differ, it will be 'Fail'.
I'm not asking for anyone to do this for me, but for someone to nudge me in the right direction. All of the tutorials/examples I seem to find on here or youtube etc seem to focus on either files or strings. I cant seem to find one which would cater for both, which is what I think i may need, although I may be wrong.
I hope that all makes sense! Huge thanks in advance for any help on this.
This is the first time i've played with TCP functions, having always used FTP before because of perceived ease.
I believe for this small file you can convert a file to bytes on client side and then send it over tcp as byte array and the server application will rebuild the file from the byte array with File.WriteAllbytes.
Save byte array to file
Here is how to get bytes from file. PS I am not very experienced just posting something.. Reliable way to convert a file to a byte[]
This should work out of box for sending byte array as tcp I never tried what I wrote but it have to work.
try
{
string Hostname = "127.0.0.1";
TcpClient Client = new TcpClient(Hostname, 10000);
byte[] packet = new byte[] { 0x17, 0x03, 0x01, 0x4c };
Client.Client.Send(packet);
}
catch (SocketException e)
{
}
Related
I'm using BIO memory interface to have TLS implemented over SCTP.
So at the client side, while sending out application data,
SSL_write() api encrypts the data and writes data to the associated write BIO interface.
Then the data from BIO interface is read to a output buffer using BIO_read() call and then
send out to the socket using sctp_sendmsg() api.
Similarly at the server side, while reading data from socket
sctp_recvmsg() api reads ecrypted message chunks from socket,
BIO_write() api writes it to the read BIO buffer, and
SSL_read() api decrypts the data read from the BIO.
The case i'm interested at is where at client side, steps 1 and 2 are done, and while doing 3, i get an EAGAIN from the socket. So whatever data i've read from the BIO buffer, i clean it up, and ask application to resend the data again after some time.
Now when i do this, and later when steps 1, 2 and 3 at client side goes through fine, at the server side, openssl finds it that the record that it received has got a a bad_record_mac and closes the connection.
From googling i came to know that one possibility for it to happen is if TLS packets comes out of sequence, as MAC encoding has dependency on the previous packet encoded, and, TLS needs to have the packets delivered in the same order. So when i was cleaning up the data on EAGAIN i am dropping an SSL packet and then sending a next packet which is out of order (missing clarity here) ?
Just to make sure of my hypothesis, whenever the socket returned EAGAIN, i made the code change to do an infinite wait till the socket was writeable and then everything goes fine and i dont see any bad_record_mac at server side.
Can someone help me here with this EAGAIN handling ? I can't do an infinite wait to get around the issue, is there any other way out ?
... i get an EAGAIN from the socket. So whatever data i've read from the BIO buffer, i clean it up, and ask application to resend the data again after some time.
If you get an EAGAIN on the socket you should try to send the same encrypted data later.
What you do instead is to throw the encrypted data away and ask the application to send the same plain data again. This means that these data get encrypted again. But encrypting plain data in SSL also includes a sequence number of the SSL frame and this sequence number is not the same as for the last SSL frame you throw away.
Thus, if you have thrown away the full SSL frame you are trying to send a new SSL frame with the next sequence number which does not fit the expected sequence number. If you've succeeded to send part of the previous SSL frame and thew away the rest then the new data you send will be considered part of the previous frame which means that the HMAC of the frame will not match.
Thus, don't throw away the encrypted data but try to resent these instead of letting the upper layer resent the plain data.
Select for writability.
Repeat the send.
If the send was incomplete, remove the part of the buffer that got sent and go to (1).
So whatever data i've read from the BIO buffer, i clean it up
I don't know what this means. You're sending, not receiving.
Just to make sure of my hypothesis, whenever the socket returned EAGAIN, i made the code change to do an infinite wait till the socket was writeable and then everything goes fine and i dont see any bad_record_mac at server side.
That's exactly what you should do. I can't imagine what else you could possibly have been doing instead, and your description of it doesn't make any sense.
I am currently working on an application to change my RGBWW light strips by a Java application.
Information has to be sent via UDP packages in order to be understood by the controller.
Unfortunately, the hex number 0x80 has to be sent - which is causing some problems.
Whenever I send a byte array containing only numbers fron 0x00 to 0x79 (using DataPacket and a DataSocket), I do get an UDP Package popping up on my network monitor.
As soon as I include the number 0x80 or any other higher, I see two things Happen:
1: I do not longer get only UDP protocols, but messages are displayed as RTP / RTCP most of the time
2: The method Integer.hexToString() does not display "80", but gives me a "ffffff80".
My question: Is there something I am missing when it comes to sending hex info by UDP? Or is there another way of sending it, possibly avoiding the annoyingly signed bytes?
I unfortunately did not find any information that would have significantly helped me on that issue, but I hope you can help me!
Thanks in advance!
In ActiveMQ while using blob messages we use this as broker
String broker1 = "tcp://localhost:7005?jms.blobTransferPolicy.UploadUrl=http://localhost:7005/fileserver/"
Can anybody explain what is UploadUrl and why we need to configure for blob messages(we don't need to configure for text messages). Why it doesn't allow tcp protocol?
So plain text messages are good and easy to use, but needs to be in memory at all times. It works well with a KBs of data, or even a few MB. However, sending very large files, such as initial data loads, large media files or BI data, is not nice to keep around in memory. There may still be a need to pass the message around, route/filter based on message properties, use transactions and similar.
Blob messages is an attempt to solve the need to pass around GBs of data through the semantics of messaging. The trade off is that you have to define a streaming based server somewhere that both sender and receiver can reach. It can be HTTP, FTP, a local file, WebDAV or similar. ActiveMQ comes with a HTTP based fileserver if you have no other file area around.
At the click of a button a simple message is to be sent from one process to another, and the message would be just a simple command with string arguments, totaling something like 50 characters (definitely much less than 1k), like
DisplaySomeInfo("param1", "param2")
and satisfying the following:
must be simple (i.e. no full-blown messaging system)
must run on Windows, should run on Unix
the picture below shows my actual requirements, but it should work with any major programming language / runtime
performance is not crucial, the whole send/receive cycle should not take more than a millisecond though for such a simple message
"guaranteed delivery" etc. NOT necessary
sender does not care if a/the receiver got the message - or if there is a receiver in the first place
no encryption/authentication/authorization necessary
In wikipedia there is a long list of ways to do IPC, but the simplest one seems to be the non-connected socket option.
Are there any better ways (easier to implement/maintain/debug, more future proof, ...) to implement it than simply sending / receiving UDP packets (one message per packet, TTL=0), say coupled with a JSON (de)serializer?
For these requirements, simply sending UDP unicast packets to some port on localhost seems ideal. The only problem is that a port number has to be chosen and fixed. But if that is not an issue, simply sending and receiving UDP packets is as easy as it gets, without the need for third party libraries.
Bare-bones example for sending a UDP packet from a .Net app:
public static void SendUdpPacket(int destinationPort, string payload)
{
IPEndPoint endPoint =
new IPEndPoint(IPAddress.Parse("127.0.0.1"), destinationPort);
byte[] buffer = Encoding.UTF8.GetBytes(payload);
Socket socket =
new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
socket.SendTo(buffer, endPoint);
socket.Close();
}
The only open question is how to encode multiple parameters. But for that there are gazillions of ways, built into many languages is HTTP URL encoding.
Hi I am writing a program that will send a file from client to server using UDP socket using different packet sizes for example 512B, 1KB and 2KB and i don't want use fixed buffer size in the receiver(server).I need some codes in Java that will allow both server and client to agree upon a packet size before transfer start. Many thanks
Don't you forget that UDP packets may be fragmented, duplicated and lost? There is a whole bunch of things to take care of, starting with lost packet retransmissions.
I hate to give a "don't do this" kind of answers, but for this one, just use TCP. And if you want some user-level "packets", you can have them with TCP also (prefix each one with its length, that's enough).