Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I want to transfer some files from one point to another. Files are sensitive so transfer has to be reliable, but if I use TCP to transfer files than the speed gets slow.
How do I create a reliable version of UDP that will transfer files quickly?
What I am doing is sending an acknowledgement for every received packet. But it is reducing my transfer speed.
Is there any way that exists without sending an acknowledgment for every received packet? Can I somehow keep track of lost packets efficiently and request those packets only?
Note:: I am sending a sequence number with every packet
I guess that you could put a count value in each packet and if you received a packet that skips a value then you know that you've lost one or more and could request a resend.
However, you're starting to implement the functionality of TCP by coding for packet loss. Is there a reason why you couldn't implement that instead?
Certainly if I was transferring sensitive data I wouldn't choose UDP myself.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am trying to understand how the timestamp in rtp along with some time synchronization protocol like ntp, can synchronize the media streams. Based on my understanding I have drawn this. Please correct me if I'm wrong.
Here clock in these devices are synchronized, and rtp packet is created with timestamp 10. But due to network transmission delay the packet reaches at 11, but the timestamp is still 10. How this case is handled in rtp for proper synchronization or is it the application that is taking care of this situation?
When handling an incoming (UDP) RTP stream, received RTP packets will be buffered before they are processed. This is to allow for jitter and such. This buffering period is typically between 50 and 300 milliseconds, depending on the used network topology.
If the buffering time is adjustable at runtime, you could use this buffering period to synchronize the two streams by ear. When two streams are out of sync adjust the buffering time (delay) of one of the streams until they appear in-sync.
If you don't want, or can't, adjust the buffering period by ear you should use RTCP (RFC 3550) to synchronize the two streams. You can't just use the timestamp values in the RTP packets.
I think this website with FAQs on RTP can be helpful.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am working on Ethernet module, in which I am using IPv4 and UDP to transmit data over Ethernet.
I know, as per theory Ethernet can transmit 65K bytes of data.
But in single frame as per MTU, we can transmit only 1518 bytes(approx) of data including header, addresses.
After 1518 bytes of data, Is Ethernet module will take care of transfer for remaining data or the programmer need to write any logic for that.
In Internet i found that large data can be fragmented using IP fragmentation.
So the fragmentation procedure stack is provided by vendor or not?
Is vendor have their won Ethernet stacks to transfer huge data?
Help is appreciated.
Your application can transmit the entire payload of approx. 40K bytes as a single UDP message. This is because, internally, the IP protocol can fragment and re-assemble datagrams of up to 64KBytes for their transmission into smaller packets. Since your payload is under this limit, and IP datagram can carry your intended payload.
As the MTU in ethernet is 1518 bytes, the IP stack will fragment the message into multiple IP packets at the sending side. On receiving side, the IP stack will re-assemble the IP fragments into single IP packet having 40K bytes payload. The application on the receiving side would be able to read the 40Kbytes message only after IP stack successfully reassembles the message.
You can refer to Linux kernel UDP code at http://lxr.free-electrons.com/source/net/ipv4/udp.c.
The explanation of an IP datagram and how it can tag sub-packets for re-assembly can be found here: http://www.freesoft.org/CIE/Course/Section3/7.htm
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I want to use the c-programming language to built a small database for students. Only the admnistrator should enter delete or modify the data. I have developed this program in C. But when i close my program, the data is lost. At the beginning i thought to store these data in files (like xml) but know i thinking to store these data on hardware (harddisk or sd-card). Is it possible? Any suggestions?
You could write a separate program which acts as a "server" - that is, it runs continuously and communicates only through some sort of network interface - named pipes or TCP/IP or whatever. When your "client" program starts up it attempts to establish a connection with the server - if it does not find the server it starts it up and then establishes communications with it. Once the "server" is found the "client" requests any saved data from the "server", which the "server" then returns if it has any. When the "client" decides to shut down it first communicates with the "server", passing any data it wishes to save to the "server" which then stores it (perhaps in a file, perhaps in memory - the implementation is up to you).
Best of luck.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've been dying to implement a chat server in C and Winsock for a long time now, but I haven't taken the time. Partly, because I'm still unsure of some of the conceptual ideas about building a server on Windows OS'es for something like chat.
Here are some of the issues I've been thinking about :
How will user x connect to my server over a generic LAN
without me relying on them to type in a network address( e.g. address
could be invalid, redirected to a different server, etc. )
If I use broadcasting to solve the above problem, will that be reliable enough for chat?
Will that potentially DDos a LAN since the packets will be be forcibly handled on every machine and may take a lot of bandwidth if enough people join?
What is the difference between multicasting and broadcasting? Is multicasting truly superior?
Etc.
Per request, my definition of reliability would be that I can get most of the data consistently in sent packets. In other words, I don't mind a few dropped packets, but I do mind if the data gets messed up quite a lot along the way.
Currently, I have a lot more questions than answers, but the main point I'm getting at is this :
What is the safest and most reliable way of implementing a chat over a LAN in C and Winsock?
How will user x connect to my server over a generic LAN without me relying
on them to type in a network address( e.g. address could be
invalid, redirected to a different server, etc. )
Use a closed list of known servers, or use some broadcast based autodiscovery system.
If I use broadcasting to solve the above problem, will that be reliable
enough for chat?
Define your requirements for reliability.
Will that potentially DDos a LAN since the packets will be be forcibly
handled on every machine and may take a lot of bandwidth if enough
people join?
It's a chat... the amount of generated packets will be comparatively short and small.
What is the difference between multicasting and broadcasting? Is
multicasting truly superior?
Search the web. There are lots of resources and information about multicasting, most precisely, IP multicasting. In short:
Broadcast delivers to all hosts on a broadcast domain. Multicast delivers to all hosts that have explicity joined a multicast group, which may not be in the same broadcast domain (see last point).
Broadcast forces a switch to forward broadcast packets to all its interfaces. Intelligent switches can benefit from peeking at IGMP packets to know which interfaces multicast packets have to be forwarded to.
Broadcast cannot treepass a broadcast domain. Multicast packets can traverse a router, if it's configured to route multicast (search for M-bone)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'd like to make an app to send/receive text messages using a GSM modem. However, I've seen that a modem can only receive/send about 8-10 text messages per minute. So if I receive 200 incoming text messages within a 10 minute span (like I'm at a conference and I ask people to sign up), do they get queued up on the modem? Do I have to deal with in in my application? Are they queued up by AT&T (or some other wireless carrier)? Is there a maximum length to the queue? Any help would be great.
Thanks!
You should not have to worry about it.
You can setup the modem to store the messages internally as opposed to on the SIM by setting the preferred storage location to "ME" which will give you whatever memory resources are built into the modem - way larger than whats available on the SIM.
If that fills up, when next the device receives a message it can't handle it will report that fact back to the SMSMC which will record the failure and add the message to a retry queue.
There is no standard for the retry policy, so they may retry a few minutes later, gradually increasing the interval as failures build up upto a total retry time equaling the "validity period" setup on the senders handset, or their own upper limit.